Add ideas for Summer of Code 2006 here.

Please put your name beside them (if you put your idea in the 'ideas with willing mentors' section and aren't the mentor, please specify who is).

1. Ideas with willing mentors

If you're willing to help the mentor for one of the ideas, feel free to add your name after the existing mentors.

• rethink how we work with applets. (see also AppletsRevisited) (VincentUntz)

  • relation between applets and notification area icons
  • auto-loadable applets (for hardware status, eg)
  • create a new libgnome-applet library, containing specific widgets to easily create applets

• Performance (FedericoMenaQuintero, DevashishSharma, VeerapuramVaradhan)

  • Evolution: make sure that it can last for more than a week on a large inbox. Generate profiling data, and find leaks.
  • Evolution: bring back the on-disk-summary branch and finish it.
    • -- the disk-summary-branch will likely not be doable in the SoC timeframe by anyone without in-depth knowledge of camel and the mailer code. It's also unclear as to whether using on-disk summaries will actually cause performance degradation for setups like City of Largo (where 100's of users all run Evolution on the same system). The number of disk accesses/seeks/etc may actually cause Evolution to run slower and not faster. The disk-summary-branch, afaik, is more about lessening memory usage than actual speed anyway, so even on a normal desktop, it might be noticably slower. I think some research needs to go into this before jumping into it whole hog.
  • Evolution: why does it take so long to switch between Mailer/Calendar/Addressbook?
  • Work to reduce the number of daemons launched by GNOME. How can daemons be integrated in single processes? How can status icons which are mostly idle (resapplet, nm-applet) be "unhooked" from a running daemon until they need to be visually updated?
  • Develop tools to track the GNOME footprint during the development cycle. Are there regressions?
  • What is loaded from disk on bootup and how can we reduce it. For example: mixer_applet2 loads all of gstreamer. The volume control applet does not need to know how to play xvid files. Can we reduce overheads like this?
  • Why is the non-shared memory for a simple hello world program over 1mb. What can be done to reduce these numbers?

  • Plot timelines of the startup sequences for various programs (or for programs run during login), find slow parts, fix them.

  • GConf: there is an unfinished CORBA API for batching requests ("fetch all these keys at the same time"). Finish it, and make the caching mode of gconf_client_add_dir() use that instead of fetching each key individually.
  • GConf: fix applications which fetch a lot of keys individually by making them use the public side of the batch API.
  • Run the "cut and paste code finder" (google for it), fix those places to reduce code size. Nautilus is especially guilty of this.

• Torture test for theme engines (FedericoMenaQuintero):

  • Write a program that will call all the methods in GtkStyleClass with especially "hard" parameters: very small/big sizes, NULL hints, widgets of various types, etc.

• BluetoothManager (BastienNocera)

  • Create bluetooth manager based on prototypes
  • Obex server and client integration
  • System-wide device integration

• Evince improvements (JonathanBlandford)

  • Form support (for both poppler and Evince) bug 304575]

  • Presentation mode for Evince

• Tinymail improvements (PhilipVanHoof)

  • Using SMTP over SSL and with authentication as transport account
  • Support for Exchange storage accounts
  • Subscribing and unsubscribing IMAP folders (testing and making sure it works)
  • Creating, management and subscribing offline folders
  • Account creation wizard for the demo-ui
  • Refactoring account store type to a non-singleton type (requires adjustments to the camel session type)
  • Implementation of a libtinymail-emerge with template types like the account store type
  • C# language binding and testing the Python binding
  • Building (a lot) more unit tests
  • Testing and making sure streams work
  • Copying and moving messages
  • Sorting and thread indexing in the demo ui

• Totem Mozilla plugin enhancements (BastienNocera, RonaldBultje)

  • Mozilla bug fixes for use in the plugin
  • Better browser cache integration (enabling replay without streaming, and saving files)
  • Playlist support
  • Windows Media Player Javascript interface compatibility
  • Seeking in files without playlist (i.e. seek on the stdin stream using dbus commands to the mozilla process)

• Tinderbox Enhancements (LuisVilla4, someone from dogtail

  • work with jhbuild, dogtail, and the jhbuild.bxlug.be folks to integrate automated tests into jhbuild- basic goal for end of the summer would be that 'jhbuild tinderbox --test' or something similar would be able to automatically pull and execute dogtail tests and report them to a central server, and that all major modules would have at least a handful of basic tests.

• Gnome SANE Frontend (ÉtienneBersac) in collaboration with Martin Schön.

  • Provide facility for scanning as a library for use in plugin for various apps such as GIMP, Abiword, gthumb, etc.
  • Unified interface for each work with a scanner (e.g. scan photos, import multipage document astext, etc.)
  • Ease configuration/installation of scanner not detected by sane (e.g. hpaio devices). Maybe with a capplet.
  • Ease handling of multipage acquisition both with flatbed and ADF scanner.

• Ekiga (DamienSandras)

  • Add encryption support, using ZRTP (or other)
  • Add libjingle support into OPAL
  • Add IAX support, using libiax, in order to have IAX support. IAX is the Inter-Asterisk eXchange protocol
  • Improve the DBUS component and make it telepathy compliant (see below)

  • Write device plugins (video input & audio input/output) which use gstreamer as a backend

• Work on integration and use of Telepathy VOIP/IM framework within GNOME (RobertMcQueen, RobTaylor)

  • New protocol backends such as MSN, AIM, IRC, etc.. Or even a gnome-phone-manager based SMS backend.
  • File transfer support in Nautilus.
  • 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.
  • Representing existing IM-based extensions within Telepathy to render them protocol independent, such as Gobby's collaborative editing or gShrooms shared music.
  • Making Ekiga's UI able to talk to other Telepathy backends, eg 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.

• Work on better integration of Gossip into GNOME (MartynRussell)

  • Finish file transfer support (including a nautilus-sendto plugin)

  • Finish the work Julien Puydt started with integrating to Ekiga.

  • Finish the work on transports] to be able to configure MSN, ICQ, Yahoo!, etc accounts again.

  • Support the new Jingle] JEP that Google Talk uses.

  • Support avatars.

• Improve handling of emblems in GNOME (ChristianKellner)

  • Make sure the same folder/icon is displayed exactly the same everywhere (Nautilus, Window icon, Filechooser, Panel, etc)
  • Scale emblems for list view
  • Easier interface for applying emblems (Context menu or something?)

  • Show emblem of a folder as a stretched-out, and faded-out background in that folder (is this crack? - ChristianKellner: no totally not, we called it watermark some time ago and it'd be great to have it )

  • Easier interface for adding/creating/editing user-specifyable emblems

  • Figure out a good relationship between emblems and tags (possibly using leaftag)

• library.gnome.org (see also GnomeWeb/Library) (ShaunMcCance, BrentSmith, JeffWaugh, JohanDahlin)

  • Automatic build system for all documentation in various formats (single-page/multi-page html, PDF)

  • System to update library.gnome.org with new documentation builds
  • Commenting system

• Deskbar Plug-In Management (NigelTao)

  • Currently, Deskbar plug-ins (aka Handlers) are installed by just dumping them into a hidden directory. Some sort of plug-in management GUI (both in terms of installing new plug-ins (and their dependencies), and for discovering even more, on internet for example) would be good. See also http://live.gnome.org/DeskbarApplet/RoadMap216

    • Could this be a project that could be done in a more general way (ie, for all apps using plugins)? -- VincentUntz

• Gazpacho (JohanDahlin, LorenzoGilSanchez, MattiasKarlsson)

  • Embedded window editing mode, like gideon
  • Improved and simplified property editor which is treeview based
  • Dynamic table and box editing, to make it easier to add new children
  • Gnome support; canvas, gnomeui, bonobo
  • Embedd an editor based on gtksourceview to turn it into a simple IDE
  • Templates for common used widgets

• gnome-terminal and vte (BehdadEsfahbod)

  • Integration of "screen" with gnome-terminal. gnomebug:332148
  • Model/view split of vte, and an split feature. gnomebug:103770

• Pango (BehdadEsfahbod)

  • Vertical writing direction gnomebug:99523

  • Integrate Pango with XeTeX (notes)

• Topic-Oriented Help (ShaunMcCance)

  • I'm not sure how feasible this is as a SoC project.
  • Need to develop a suitable help file format, taking into consideration the needs of the help system and what sort of stuff we actually write.
  • Need to develop the tools to format and display help pages, including integration into Yelp.
  • Would be best to work with documentation people to convert an existing large-ish document while developing, to see how well things work.

  • Rough sketch: http://www.gnome.org/~shaunm/quack/mallard.xml

• 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

• Scripting architecture for desktop scripting (HubertFiguiere)

  • Rough sketch: http://www.figuiere.net/hub/blog/?2006/04/16/397-desktop-scripting

  • Define the base protocol and implement the scripting interface, using D-BUS and a Gtk application

  • Implement a language interface with the scripting interface for JavaScript (or another language, to be discussed)

  • Add scripting to GNOME (proposed by VincentUntz, would need a mentor who knows more than I do ;-))

    • something could be done with dogtail, I suppose
    • Patch apps to be dbus-ified and support the dbus introspection API so that the scripting framework could discover services at runtime.

    • Investigate EveryGUI as a possible example of an apple automator style script designer.

    • Check GNOME Command-line Interface

• Font Management for the Desktop (BehdadEsfahbod)

  • Have an application to create font sets and (un)install fonts
  • Have a library to access the font sets
  • Provide a way for application to refresh font lists while they're running (and to update font sets changed by the font manager)
  • Probably add the basic support in Gtk+, and have the application manage the data that Gtk+ will use.

• GNOME Automation using Linux Desktop Testing Project - LDTP (NagappanAlagappan, PremkumarJ, EmilyChen, VeerapuramVaradhan)

  • Write LDTP automation scripts for the following GNOME applications
    • Evolution
    • Nautilus
    • Gnome-Control-Center
    • GNOME-Panel and applet
    • Evince
    • gedit
    • Banshee
    • Rythmbox
    • Totem
    • Epiphany
    • Beagle

• Glom enhancements (separate tasks) (MurrayCumming)

  • Drag and Drop layout editing: Add a pallete of layout items (fields, portals, buttons, etc) and allow them to be dragged onto the layout, showing visual feedback as they are moved around, before being dropped. The items, and a non-drag-and-drop layout editor, already exist.
  • Charts: Add a chart portal layout item, with appropriate options, to draw charts based on related records. This should reuse the libgoffice charting API.

  • Calendar View: Add a calendar portal layout item, with appropriate options, to present related records as days on calendars, by specifying a date field in the related table. This requires a small API addition to GtkCalendar to make it display extra information for each day.

  • 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)

• Glade-3 (TristanVanBerkom)

  • Polish and complete the base GTK+ catalog (including writing a toolbar editor)
  • Implement accelerator key editing.

  • Write a GtkWindow parenting widget (a little black magic here) to allow IDEs to embed

    • glade-3 runtime toplevels in arbitrary parts of thier UI.

  • Support for non-GtkWindow toplevels in glade projects

• Language packs in the build system - intltool, others (DaniloSegan)

  • Extend intltool to support re-merging stuff from MO files into all the files it supports (eg. start with gnomebug:309566)
  • Add supporting .m4 rules to build langpacks
  • Rules for installing untranslated .in files
  • Rules for MO file installation and reuse
  • Perhaps push it into at least one distribution?

  • ShaunMcCance: Doing this really well woud also mean putting translated documentation into language packs. I can provide guidance on the gnome-doc-utils work that would be necessary to make this happen.

• Tomboy (AlexGraveley)

  • Keep two or more tomboy note collections totally in sync
    • A central server is needed to keep the global note repository
    • Sync'd tomboy processes do not need to maintain constant contact with the server
    • When a tomboy instance joins an existing sync account, the local tomboy instance adds the local notes to the server as new notes
    • If a conflict occurs, (two machines edit the same note before they are able to sync with the server) one edit wins and the other becomes a new note
  • Send a note to another Tomboy instance
    • Notes should be able to be emailed as attachments
    • A mime-type handler imports the note into the local tomboy
    • A new note should always be created by the import
    • Internal links should be re-evaluated in the new note
    • The new note should be immediately displayed
  • Share a note with people other than yourself, including updates without letting them edit the note
    • Tomboy needs a new "read-only" mode
    • Read-only notes can be deleted, which will stop the watch
    • Read-only notes can be cloned into editable notes
    • "Watchers" should be able to go offline and still have access to the last version of the watched note. When they go online again, the latest version should be available
    • Edited "watched" notes should sync occasionally
    • Watched notes should show in the UI that they are being watched
    • A note can be watched by more than one external Tomboy
    • UI should allow the owner of the note to stop a note from being watched
    • Internal Links should be re-evaluated by the watchers so links make sense, or (easier) internal links should be ignored
    • Note offers should be recieved via email as an attachment
    • A mime-type handler imports the note
    • A new note is always created
    • The new note is displayed on the screen immediately

• Implement the interactive XKB configuration files editor (SergeyUdaltsov)

  • Minimal - assisted text editing with "Preview". Maximum - fully graphical editing.
  • Essential: checks for validity and good practices

• Add Annodex support to Totem (Mentor: BastienNocera, need GStreamer and Annodex mentors)

  • Display tables of clips, metadata and annotations in the Movie Player (sidebar)
  • Should support both the desktop GUI and browser plugin
  • Should link to browser directly when used inside the Movie Player
  • Should support both xine-lib and GStreamer 0.10 backends
  • Student would be assisted by Annodex community, might be worth having a mentor in each camp

• GtkMathView (Mentor: LucaPadovani)

  • design/implement cursor movement on MathML formuals

  • design/implement selection, cut & paste, do & undo of MathML (sub-)formulas

  • implement GTK+ WYSIWYG editor for MathML formulas (to be used also in AbiWord)

• Infrastructure for getting useful backtraces from know binaries without debug info (Mentor: FernandoHerrera)

  • A small client side library for getting available info on the client (crashing side) like mem maps, md5sums of binaries, stacktrace
  • A server side infrastrucure that allow to install and track every know binary on the world and processes the incoming reports to populate stacks with functions names and so. Also some XML-RPC/SOAP interface would be required to send/receive reports, and a web front-end to consult them.

  • initial description of this idea

  • It would be great to do this work in collaboration with other projects, defining an standard XML-RPC or SOAP way for sending the crashes and share the server-side infrastructure. Mozilla bug. Maybe also maemo people and KDe would be interested on this.

• Epiphany:

  • Combine the notions of browser bookmarks and history by implementing a simple user interface and SQLite-backed database as part of the Epiphany project. This will involve some innovation in determining "what exactly is a bookmark?" and "how should the user organise things?", as well as database efficiency problems. The database should be simple to extend so that additional information can be stored as new functionality (custom icons, user notes, etc) are provided by Epiphany extensions. See also Epiphany/BookmarksHistoryIntegration (mentor: PeterHarvey)

• Jokosher (Mentor: JonoBacon)

  • Implement effects support and support LADSPA plug-ins
  • Improving Latency - Improve GStreamer's ability to handle low-latency audio streams.
  • VST Gstreamer Bridge - Write a bridge to allow the use of VST plug-ins as nodes in a GStreamer graph.

  • Plugin manager (Mentor by StuartLangridge) - Allow plugins to Jokosher that do things, and make them really easy to install and discover.

• GStreamer:

  • Reimplement the Graphical Pipeline editor for GStreamer in Python for GStreamer 0.10. The old 0.8 version in C can be seen here gst-editor but we want do restart the project in Python instead to make it more maintainable and quicker to develop. (mentor: Thomas Vander Stichele and Edward Hervey)

  • Sound like a UML application. How about extend Gaphor or Dia?

• GStreamer:

  • Bluetooth integration in GStreamer. It does require a little bit of hardware to pull off but there are two independent parts that are each self-contained.
    • stereo audio (requires bluetooth adapter plus stereo headset) - bt signaling plugin and a sbc codec plugin (codec is working btw)
    • mono audio (requires bluetooth adapter plus standard bt headset)- bt signaling plugin only
  (Mentor: Brad Midgley)

• GnomePanel enhancements (VincentUntz)

  • make it work nicely in RTL environments (bug gnomebug:149886)
  • make the menubar/main menu totally editable
  • work on corner panels (bug gnomebug:107622)
  • use real transparency for the panel if available
  • other enhancements you feel would be great

• MindMap/Generic Graph Widget (ChristianKellner)

  • build a Gtk Widget that could be used to display "Graphs" like MindMaps, Concept Maps or better Graphs in general

  • Use the new ccc canvas
  • Model-View-Controler Concept

• Implement P2P calendar-sharing functionality for evolution (proposed by VicentSegui):

  • There are some different approaches to do this with Evolution, here are 3 ways that quickly come to mind:
  • Complete SWIGforEDS and implement a trivial calendar-share program This would involve the following tasks:
    • Complete a SWIG python binding for the calendar API in e-d-s. (4 weeks estimate).
    • Write a specification for sharing and accessing calendars with Jabber (4 weeks estimate) which should allow:
      • Remote retrieval of calendars (e.g. user A can read user B shared calendars if user B has given permission)
      • Auto discovery of shared calendars (users do not have to explicitly subscribe to friends calendars)
      • Modification of calendars with fine grain control, up to event level for instance (user A can write/modify in user B calendars if granted permissions).
      • Notifications. For instance user A can invite user B to a meeting and this will be reflected in B's calendar.
      • Offline support. See PEP 016 and Philipp Van Hoof about this.
    • Write a Jabber bot (and a GUI for configuring it) that (2 weeks):
      • Uses previous binding and specifications to work
      • Shares e-d-s calendars with authorised users in read-only mode (users can't modify remote calendars).
      • Is capable of discovering automatically other users calendars and retrieve them
    • Implement a plugin in Evolution that communicates with the Jabber bot to dynamically add discovered and retrieved calendars to Evolution lists of calendars (2 weeks)
  • Write a Calendar backend capable of reading and writing calendars via Jabber. Involves the following tasks:
    • Write a specification for sharing and accessing calendars with Jabber (4 weeks estimate) (see proposal A, point 2).
    • Write an e-d-s calendar backend that implements the previous API (8 weeks)
  • Write a SWIG (?) interface to allow backends written in other languages.
    • Modify e-d-s so it can load backends written in other languages (3 weeks)?
    • Write a specification for sharing and accessing calendars with Jabber (4 weeks estimate) (see proposal A, point 2).
    • Write an e-d-s calendar backend with python that implements the above specification (5 weeks)

• GtkSourceView improvements (Mentor: PaoloMaggi)

  • Finish and test the new syntax highlighting engine
  • Port the printing code to the new gtk+ printing infrastructure
  • Rewriting the undo manager

  • Take advantage of new GtkTextView features (e.g. has-selection property)

  • This and that

• Java-Gnome improvements (SeanCoughlan)

  • Implement the Handle as a long (used as the proxy)
    • simplify and reduce JNI code, simplifying autog-eneration
    • improve cpu performance, reduce memory pressure
  • Implement a new binding using auto-generation
    • New, fun and interesting bindings like gnome-bluetooth or libpanel
    • Complete the E-D-S bindings and write a solid useful application that uses it
    • Use pygtk for auto-generation inputs
  • Investigate auto-generate some of the existing bindings

  • Help bring one of the many existing Java-Gnome Applications into the limelight

• Gnome-DB improvements (VivienMalerba)

  • Add data definition support to Libgda in a way independent of the actual DBMS used
  • Work on the different DBMS providers (adaptators) to make all of them work correctly (at the moment SQLite, PostgreSQL and MySQL are the most advanced)
  • Make Libgda/Libgnomedb/Mergeant fully work on Windows (some work has already been done and there should not be any real difficulty)

2. Other ideas

If you're willing to mentor one of those ideas, feel free to move it in 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.
  • Localisation (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
• Make a library for single-instance apps (Elijah Newren)
  • Many apps, when launched, will contact a previously existing instance and tell it to open a window and then exit so that only one instance of the app is running.
  • Each and every app seems to roll their own method for doing this, meaning nearly all of them are buggy with respect to things like startup-notification and focus-stealing-prevention and each and every one has to be fixed individually.
  • Making a library to handle this stuff (probably similar to KUniqueApp in the KDE world) would allow us to remove a lot of code duplication and fix a lot of repeated bugs.
  • I might be able to serve as a mentor for such a project -- but I have so many other suggestions in here plus a dissertation that needs finishing that I'm not sure.

• 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+: 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

• 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 HTTP form buttons in Epiphany look like any other button in regular GNOME applications. (Make the buttons based on GTK widgets) (proposed by GabrielHurley)

• 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 listenning" 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) gnomebug:95043

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

• GStreamer GSmartMix : write a smart audi mixer and get rid of some problems related to esd/gstreamer (MarcAndreLureau)

  • provide an audio sink managed by a dbus daemon that decide from a policy which transformation should automagically be applied
  • normalization, volume level, and fading
  • mutual exculsion, lifo, fifo
  • each application will be registered in a class of policy. Each instance of application can override it's class parameters by a manual change in a mixer. A class could be: music, video, desktop, browser, voice, default. Generally, you don't want to hear music with video (interclass policy) or two music player at the same time (intraclass policy). This project of sink will be integrated in gnome seamlessly since it's just the default sink that would be changed.