The information on this page is out of date! Please refer to the Women's Outreach page instead.
Here are some potential projects for the GNOME Women's Summer Outreach Program. (Applicants are encouraged to submit their own ideas if none of these appeal to them.)
If you are a current GNOME developer:
- please consider adding something to the list, even if you don't have the time to mentor it yourself
If you are considering applying for one of these projects:
please contact the program coordinators and let us know what you're interested in; we'll put you in touch with possible mentors to chat about how the project would work.
- Implement profile based approach in Evolution Mailer. (possible mentor: Shreyas)
- Make each folder understand profiles. Depending on profile rules handle folder properties like visibility, connection handling, sync etc. Make autosync a folder property, so that users can choose folders to sync at startup rather that the current approach of syncing just INBOX or every folder.
Continue on the Camel summaries mmap work that PhilipVanHoof did. For example data alignment on ARM architecture is still a problem. Also watch the discussions about it on the evolution-hackers mailing list.
- Proper synchronization of PIM
- This project has already been started by someone outside the WSOP program. However, please contact Corey Burger (address at his link above) for possible similar projects, if you're interested.
Write an Evince (poppler) based plugin for mozilla.
Integration with GNU screen
- Interactive search through scrollback
- Display-independent terminals, the ability to attach/detach terminals from an X server
Fading between tracks in Rhythmbox
- also "gapless mixing" support?
- Some kind of "intelligent listening" support in Rhythmbox, keeping track of which tracks are likely to be played after each other.
(possible mentor: JamesLivingston)
- 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. See discussion on the gnome-multimedia list.
Common music control interface: A number of music players have DBus interfaces 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.
File transfer support in Telepathy spec, Nautilus and XMPP connection manager (RobertMcQueen)
- Displaying presence/capabilities within Evolution or Contacts (using Galago) and requesting chats/calls with people.
- Drag and Drop layout editing: Add a pallet 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.
Tomboy visualisation of the links between notes -- perhaps graphviz output.
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
gnome-settings-exporter: import/export desktop settings using gconf.
gnome-vnc-viewer: a GNOMEified front-end to VNC. See James Henstridge's old gnome-vnc-viewer work.
planner-applet: An applet for project management, possibly a front-end to Imendio Planner.
Compositing bling: work on compiz/metacity plugins, possibly porting compiz plugins over to metacity.
A piece of presentation software for GNOME. Maybe a frontend to Magicpoint.
Bug-buddy support for Pygtk or GTK# apps. When a C or C++ gnome application crashes, gdb is invoked by libgnome. When a C# or Python app crashes, nothing happens. We should attach debugging information from the Python/Gtk# debuggers as well as from the C debuggers. (Possible mentor: Fernando Herrera)
- gnome-font-manager (possible mentor: Behdad Esfahbod)
- 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-bittorrent: A fully GNOMEified bittorrent client for GNOME, using gnome-vfs etc.
- Tools for people with multiple displays
- GNOME needs a coherent control panel to set how a machine with more than one graphics card/monitor in should behave. Some examples of behaviour that should be configurable: separate desktop backgrounds for each screen, separate screensavers, proper gnome-panel support
- Some work could be done at the Xorg level here, and maybe even Xgl, multiplexing hardware X servers over to one single one. Keith Packard would be the best contact.