Mentored Projects

The information on this page is out of date. Please refer to GNOME Love for current advice or see the current list of project mentors.

There are many ways to get involved with GNOME, but maybe you would like to take on a more substantial project. Here are some tasks that need a few weeks of your time. The GNOME developers listed here would like to introduce you to GNOME and help you to complete these tasks, in the hope that you will make a meaningful contribution and remain involved in GNOME after you've finished.

Many of these project ideas are left over from GNOME's Google Summer Of Code.

Please contact your potentional mentor directly via email. Remember that you might be competing with other potential mentees, so try to convince the mentor that you will really give enough of your time, and try to show that you have done some investigation into the project. This chance is open to everyone, regardless of your student/employment status. What counts is enthusiasm and the ability to learn.

GNOME Developers should feel free to add their ideas here and link to further details.

Ideas With Willing Mentors

The names in brackets are the names of the mentors.

• Glom enhancements (separate tasks) (MurrayCumming)

  • Charts: Add a chart portal layout item, with appropriate options, to draw charts based on related records. This should reuse the libgoffice charting API.
  • Scripting: Add python API to allow button scripts to automate Glom. For instance, to navigate to a form on a table, to do a find, sort the result, and print an pre-defined report. Also, to add/remove/edit records programatically.

  • Add support for other Database Engines, maybe using extra libgda API. (DanielEspinosaOrtiz)

• Translation of Gnome applications and/or documents. (ClytieSiddall)

  • This offer is currently prioritized for female translators only, and is not limited to Gnome translations, but covers Free Software translation in general. You don't need to be a new translator: if you want to translate or are already translating, and would like some support in learning the procedures or in the translation task itself, please contact me. I'll look forward to meeting you.

• Add more lockdown feature to the desktop (VincentUntz)

  • there are a lot of areas where we should provide lockdown facilities, like "do not allow file creation", which touches a lot of the desktop modules
  • defining some core lockdown features and making all modules know about them is an important work
  • it probably also involves some work on pessulus, to enhance it

• Telepathy project enhancements (RobertMcQueen)

  • Avahi backend for XMPP connection manager
  • File transfer support in Telepathy spec, Nautilus and XMPP connection manager
  • A Telepathy backend for Gossip to make use of connection managers for chatting any protocol.
  • Displaying presence/capabilities within Evolution or Contacts (using Galago) and requesting chats/calls with people.
  • Making Ekiga's UI able to talk to other Telepathy backends, (ex. for making Google Talk calls with our XMPP backend.)
  • Making Ekiga available as a Telepathy connection manager for providing H.323 and SIP based functionality to other programs.

Other ideas

If you're willing to mentor one of these ideas, feel free to move it into the first part of this page and add your name as mentor.

• create a library to handle plugins/extensions. (VincentUntz) (don't know if it's a good idea and if I'd be able to supervise this one)

  • define the required features (dependency handling, conflicts, etc.)
  • look at the various implementations out there
  • create a library
  • port some apps using plugins/extensions to this library

  • NicolasTrangez: I started to work on something like this a year ago. Generic support for C an Python plugins was done, dependency handling should be fairly trivial. Not maintained for quite a long time though. If people need this, I could work further on it... See OpluginManager

  • Take a look at the Evolution/Eclipse plugin architecture (NotZed tried to copy the Eclipse plugin arch when he designed the Evolution EPlugin system) - perhaps EPlugin can be used as a starting point.

• Implement profile based approach in Evolution Mailer. (Shreyas)
  • Make the folder understand profiles. Depending on profile rules handle folder properties like
    • visibility, connection handling, sync etc.
  • Make autosync a folder property, thus user can choose folders to sync at startup rather than
    • the current approach of syncing just INBOX or every folder.
• Proper synchronization of PIM (Noname)

  • Add user interface for OpenSync

  • Fix up proper support in OpenSync for major cell phones and PDA's

  • Integrate with Evolution
  • Possibly integrate with gammu and similar apps
  • Integrate with the bluetooth-manager mentioned above, as well as current GNOME phone utils.
• Create compositing BLING! (Noname)
  • Add possibility to use compiz plugins with metacity
  • Add framework for apps to know if compositing is enabled
  • Implement cool and USEFUL effects to different aspects of GNOME
  • Use true transparency instead of hacks (like in panel, gnome-terminal, etc.)

• GnomeOnRails (Noname)

  • start making it as easy to write a basic GNOME app as it is to write a basic RubyOnRails web app. In particular, scaffolding for new projects, and perhaps integration with sqlite for basic database ops similar to RoR's automagic field generation from database schemas.

• PatchSquad (Elijah Newren)

  • Start and lead a new group similar to bugsquad, but whose purpose is doing 'pseudoreviews' of patches.
  • Group would focus on finding problems in submitted patches rather than accepting patches, though they might add 'works for me' comments.
  • Goals of the group:
    • reduce load on maintainers, and let them focus on the more important patches
    • make more people familiar with the code

    • avoid the chicken-and-egg problem in getting more patch reviewers (see Google Cache of J5's blog post on "D-Bus and the Patch Approval Process" -- which explains this issue and provides other motivation for such a group)

    • Reduce amount of time contributors have to wait for a patch review
    • help maintainers find good candidates for co-maintainers
  • Further outreach/integration points:
    • Need to write a patch-pseudoreview guide, similar to the bugsquad triage guide
    • Should probably have a mailing list and irc channel
    • Would be cool to have pseudoreviewers show up on weekly bug summary

    • Add a 'pseduoreviewed' patch-status, for convenience of maintainers (make this show up in browse.cgi & patch-report too)

  • Disclaimers: I don't know if this would satisfy the criteria of SoC, as code review isn't necessarily the same as coding. There are bits and pieces of coding, but lots of code-review and even more management and perhaps even marketing type things involved. Also, I'm pondering proposing this (or a number of other competing unrelated ideas) as a project that I'd do...

    • BehdadEsfahbod: I think this does not qualify. The SoC FAQ says for example that writing documentation is not accepted.

• Natural language description of GTK+ widgets layout (GoranRakic)

  • Add new feature for gnopernicus (and/or Orca) which takes advantage of how GTK+ works (widgets and containers principe) to reate a run-time description of widgets layout.
  • Using accessibility infrastructure (AT-SPI), we can fetch widgets tree from window and then use filler (container) properties to learn about real layout and construct natural language description of window or dialog.
  • Send generated description to gnome-speech or Braille monitor/device.
  • Localization (l10n) issues need to be covered

• Revive Gnome Packaging Project (Elijah Newren)

  • Might be easier to pick a subset of the goals, e.g. 'setup build system providing weekly parallel-installable cvs builds on Fedora' or something like that and then expanding instead of swallowing too much at once

• Shared music player infrastructure (JamesLivingston)

  • Most music players are consolidating on GStreamer as the playback backend, but there are many other pieces that would be good to share. Would require buy-in from several music players (Banshee, BMPx, Muine, Rhythmbox, et al) and possibly some KDE ones too (amaroK, JuK, et al).

  • Common music database: having a common database would mean not having to tell each player where your music is, and allow users to switch players without losing information like play counts and ratings. Difficulties exist because various players expect different things from their database, store different information and use it in different ways. Some discussion on the gnome-multimedia list http://mail.gnome.org/archives/gnome-multimedia/2006-March/msg00001.html.

  • Common (DBus control) control interface: A number of music players have DBus interface that they can be controlled with. It would be nice to have a common interface, so applications can tell players to do things without caring which one the user prefers
  • Portable Audio Player access library: libgphoto exists to allow photo applications to access digital cameras without caring about the implementation details specific to each camera. We need a similar library for audio players.

• Dynamic change UI language with libglade (Noname)

  • Gtk+ widget has no concept of gettext. But since libglade keeps a tree of glade XML, libglade can reset the Label and Tip content (anything that is marked translatable) for widgets by reloading the original text through gettext(msgid) under a new language environment. Widgets not managed by libglade have to handle their language switching manually, but any widgets managed by libglade should have automagical language switching ability unless be told not too (a new attribute in xml?).

  • ShaunMcCance: First, the user's language is set as an environment variable, which we have no way of changing at runtime. Second, lots and lots of applications do have to build parts of their interface manually, or have to construct strings programmatically. Just doing a libglade hack won't help anybody, and I don't think it's even a good starting point for being able to change languages dynamically. Doing this right is a lot more work.

  • ChristianNeumair: I agree with Shaun, this requires more fundamental work. We'd need a language management framework that is not restricted to environment variables, but incorporates their information unless specified otherwise by the user. We could have a GtkSetting for the language, and set LANG at login time if its previous value is overridden. The widgets would be able to reconstruct themselves as they receive the GtkSetting change notification, so at least the stock widgets can be auto-reconsidered when they language changes. The problem is really that custom widgets are often constructed like foo_widget_with_str (_("foo label, translate me!")); so the lookup takes place at construction time (actually, even before invoking the constructor). Maybe we need new calls similar to gtk_action_group_set_translate_func and gtk_action_group_set_translate_domain that can be set for each widget, and will make GTK+ reconsider each string upon GtkSeetting language changes, and convert the above call to foo_widget_with_str (N_("foo label")); to make gettext aware of the string but still pass the raw (i.e. untranslated) string to the constructor. This poses a semantic change that can not obviously be reflected by the API and will break many apps during transition. Unless somebody comes up with a uber-smart solution I'd call it 3.0 material :/.

  • BehdadEsfahbod: Yeah, this is 3.0 material for sure. And requires ["LocaleProject" Giulia].

  • mozbugbox: I like the idea of glade, i.e. mark strings with translatable property. You set the string that need to be translated as foo_widget_with_str(G_("some label")) where G_("some_label") will return a translatable object(a struct or a char* with marker). foo_widget_with_str then recognize the translatable object and save it. On display, gettext was called on the original text under current gettext domain. OK, now I wish C can do function overload.

  • Note: GTK+/DynamicLanguages

• PHP language bindings to GNOME (AnantNarayanan) (Looking for probable mentors, someone from the pyGTK team?)

  • Write bindings for GConf, Bonobo, Gnome, GnomeCanvas and GnomeVFS a.k.a the gnome-python package.

  • Write bindings for libegg, nautilus etc. a.k.a the gnome-python-extras package.
  • Integrate PHP-GTK with the GNOME Bindings release set (2.16 or 2.18) (as gnome-php and gnome-php-extras?)

• Evince mozilla plugin (MitjaPagon)

  • Write an Evince (poppler) based plugin for mozilla.

• Conversation View in Evolution (NigelTao, ChristianKellner)

  • I think this was a SoC idea last year, but did it not go anywhere or am I just blind and missed it?? Basically, have www.gmail.com style grouping of e-mail into conversations. --Isnt this available as a plugin? Enable the subject threading plugin. It works quite well. (I have done some rework here, GtkHTML seems to be a problem for me - my code lives in gicmos_rework in cvs, Ill commit missing pieces soonish)

• Add OpenGl support to Gtk+: wiki:gnomebug/119189

• Add Evolution Filters to procmail export plugin (ThomasBaker)

  • write out procmail version of evolution filters to .procmailrc.evolution that could be included in the users regular .procmailrc
  • no need to parse .procmail filters, just a one way export so evolution can be used as a nice front end to creating procmail filters
  • add option so that everytime the evolution filters are modified, the plugin exports a new .procmailrc.evolution file
• Qt/Gtk engine like gtk-qt-engine
  • Applications in KDE will use Cairo to render Qt/kdelibs applications. Similar to gtk-qt-engine, so KDE applications would look like GNOME applications in the desktop.

• DVD playback in Totem using GStreamer backend (RonaldBultje - I can help with module/totem bits, but someone from the gstreamer team should (co-?)mentor this for the politically sensitive gstreamer bits)

  • Port the relevant pieces of GStreamer-0.8 over to 0.10 (dvdnavsrc particularly, but will also require work elsewhere)
  • Implement DVD-specific code in Totem's GStreamer backend (bacon-video-widget-gst-0.10.c)
  • when time allows, basic optimization work should be done for the image-mixing bits, since this is one of the performance culprits in the old (0.8) implementation.
  • In the end, DVD playback should work 100%, such that a DVD plays back when clicking "open disc" or when totem is autostarted after a DVD is inserted, including (but not limited to) DVD menu navigation including audio/subtitle/scene selection. All Totem UI controls for DVD playback (title, chapter navigation, subtitle/audio stream selection, etc.) should work too
  • Ideally, there would also be work to make this easy to install for common distributions, including some pointers / helpful error messages if relevant modules are missing and how those can be installed

  • TimMuller: As much as working DVD playback would rock, I am not entirely convinced this is a good SummerOfCode project, as

    • it doesn't really teach the prospective hacker much transferable knowledge about GStreamer
    • it mostly "just" involves fixing tricky core stuff (newsegment handling) in the various already-ported dvd-related plugins (dvdnavsrc, dvddemux, dvdsubdec, and possibly adding newsegment handling to some video mixing plugin) (this is also the stuff Ronald was refering to as allegedly 'politically sensitive')
    • dvdnavsrc is already ported (it's just disabled in the build for now)
    • the dvd bits in totem are also ported already in the 0.10 backend

• Improve pamusb support in gdm (proposer: JeanChristopheJaskula, possible mentor: BrianCameron)

  • it will be possible to log in just by insertion of a usb key. This usb key must contain a DSA key which is needed to be authenticated. (see www.pamusb.org for more details)
  • modify gdm interface to remove unnecessary widgets like text aeras. These widgets could appear with a key combination (like CTRL + l)

  • use the previous DSA key to interact with gnome-keyring (Idea from VincentUntz)

• Implement BracketView for Nautilus (as proposed by ueluei)

• Create a GTK+ client to bugzilla (proposed by VincentUntz)

  • this is just an idea, not sure it is good
  • would need cooperation with bugmasters
  • python looks like a good choice
  • looks like bugzilla-buddy used to do this

  • I'd appreciate people fixing the following bug and all the blockers first: https://bugzilla.mozilla.org/show_bug.cgi?id=webservices -- OlavVitters

• Google calendar support for evolution-data-server & evolution (proposed by VincentUntz)

  • probably too short for a project, so would need to be done with some other stuff

• Epiphany:

  • Make Epiphany be able to use firefox extensions (proposed by VincentUntz)

    • this is just an idea, not sure it is good or doable
    • would need to ask epiphany people

      • Would require javascript-GTK bindings, at least (ReinoutVanSchouwen)

      • I'd say this is impossible for any extension that has any UI (chpe)
  • integrate downloading with Nautilus (proposed by chpe)

  • Children's Browser (CoreyBurger)

    • See Epiphany/ChildrensBrowser

  • Port all the remaining bits of galeon to Epiphany: Epiphany/GaleonIssues

  • ...or anything challenging enough from the Epiphany/RoadMap216

• Make the D language more suitable for building Gnome applications (proposed by JamieMcCracken)

  • Integration wth Anjuta (including syntax highlighting)
    • This means implementing syntax-highlighting in gtksourceview and/or scintilla

  • Help make the GTK biindings more complete (see DUI project at http://dui.sourceforge.net/ )

  • Add bindings for some of the commonly used gnome libs (like GConf and Gnome-Desktop)

• Make an "intelligent listening" plugin for Rhythmbox ( LionelDricot look for a mentor to do it)

  • Artificial Intelligence application that will try to feed your playlist with songs you are willing to hear in a given mood.

• Pango:

  • support arbitrarly named font variants (style or weight) wiki:gnomebug/95043

  • support advanced OpenType features (localized glyphs: wiki:gnomebug/325714 and others) and interface in Gtk+ font selector