1. General Info

It's important to note that this list is not exclusive: if you are a student and have an idea that is not listed in our pool of project ideas, don't hesitate to apply for your project. It's probably a good idea to ask people in the GNOME community if they think your idea is good, though. Also, if the development team is already working on something similar to your idea, they may be less likely to accept your proposal, so ask on the project's mailing list or IRC channel (lots of people lurk on IRC; don't be surprised if it takes an hour for your question to be answered, and don't just leave if nobody answers within five minutes!).

The ideas do not have to be only about modules that are in a GNOME suite. If it's a project on GNOME-related software that can benefit the GNOME community, it's also good to list it here.

When adding a project idea, please try to follow those guidelines:

• if you're interested in mentoring it, put your name. If not, then just leave it blank.
• do not list multiple idea with only one item. Use multiple items instead.
• briefly explain why this would be great for GNOME.
• do not write lots of text to explain your idea. If this is going to be long, maybe it's worth creating a page for it?
• make sure students who do not know much about all GNOME modules can understand the proposed idea.

2. Ideas

2.1. Rock Stars

• Make Evolution's collapsed thread mode really useful (mentor: SvenHerzberg and ChristianKellner)

• Benefits: Currently evolution can reorder collapsed threads according the the date of the last email of the thread

• Requirements: C programming, knowledge of evolution

• Note that this is about making several things work pretty well (tracker: https://bugzilla.gnome.org/show_bug.cgi?id=387309)

• Note: this might be a bit small, but could be extended to "kill annoying evolution behavior" (and just adding other bugs)

• Brave new X11 world (mentor: ChristianKellner and others)

• Benefits: Make GNOME be a state of the art desktop X11-wise

• Requirements: C Programming (GObject)

• With the hotplug-input support and randr-1.2 support in the upcoming release of Xorg 7.3 (scheduled for May 2007) it would be very cool to bring these features to GNOME in a eye-candy, userfriendly way. With xrandr it is possible to hotplug Displays at runtime and we should pimp up our control center capplet to support for that. Also support for different profiles (presentation mode e.g.) and a small application to easily switch between those profiles with a keyboard shortcut sounds like a must. We also need desktop integration for the input hotplug stuff. See the links for details.

• To cite Keith "Rockstar" Packard: "And, of course, it would be fun to see some applications starting to use this [(randr 1.2)], in particular KDE and Gnome both have screen size setting applets which could see some significant enhancements now." Do I need to say more?

• I can help mentoring for the panel changes (which are important, since sometimes you'll want panels on the second screen, and sometimes you don't want them) -- VincentUntz

• Implement PDF Annotations support in Evince (mentor: CarlosGarciaCampos)

• Benefits: support common use cases when you're working with an interesting document, as hilight, annotate, underline and mark text. GNOME Community have tried before to develop this, and even in last year's Summer of Code there was a project with this objetive in mind, but, without sucess (no actual work is done towards achieve the objective).

• Requirements: C/GTK programming, Poppler knowing, Evince's internal knowleadge.

• See last year's proposal for more information, or our somewhat old task description.

• OpenGL integration for Gtk (mentor: BehdadEsfahbod)

• Benefits: Make it smooth and easy to use OpenGL in a platform independent way from our beloved toolkit.

• Requirements: C programming, GTK/GDK internals

• The integration should be straight-forwareded and easy to use. Maybe in a similar way as done with cairo. Somehow get a OpenGL "context" and just "draw" right away. See Bugzilla Bug for a discussion and maybe a starting point but keep in mind that we probably don't want any integration of any existing GL Widget but a new approach. BehdadEsfahbod is most likely the one to speak with about that.

• Integration of bookmarks/history functionality (mentors: ReinoutVanSchouwen, XanLopez, JamieMcCracken, and others)

• Benefits: The current History functionality in Epiphany is quite limited. It would be great to bring bookmarks and history under the same umbrella, making them available to all of GNOME instead of just the web browser. Could be a perfect use case for Tracker;
• Requirements: Existing knowledge of RDF gives a head start but is not a prerequisite, some background in user interface design is preferable.

• Explanation: The basic idea is that bookmarks can be viewed as persistent history items. The bookmarks/history UI could be adapted to fit this concept. A page containing brain storm information can be found here: Epiphany/BookmarksHistoryIntegration

• Integrate desktop search engines into GtkFileChooser (mentor: FedericoMenaQuintero)

• Benefits: Simply put, there are 2 major desktop search engines for Gnome, Tracker and Beagle. They both can be queried from Nautilus, and have powerful independent search tools. What prevents them from competing with something like Apple's Spotlight is their lack of integration with native file choosers.

• Requirements: There is a working patch that supports both Beagle and Tracker, but there are some missing things that it needs to do. You need to finish this patch, and get it either committed to the upstream GTK+ tree or accepted for inclusion in the next release.

• Bugzilla Bug

• Note: Beagle currently has this listed on their SoC page as well, but it just refers users here, its something that the Beagle community would love to see. But these are not conflicting projects, as the code change would be almost exclusively Gtk.

• Enhance Mango to allow self-service of GNOME account data and streamline GNOME account setup (mentor: ?)

• Benefits: This would lessen the burden for the accounts team; speeding up the account creation process.

• Requirements: Very good knowledge of security problems; PHP (object orientated); XSLT; XML; some LDAP (can be learned during SoC).

• Mango is used by the accounts team to create the ldap accounts. Currently to request an account request tracker 3 is used. Mango should be used to avoid having accounts team find out the maintainer & request confirmation. The accounts team should only review the data and do the final accept/reject. Mango should do all the rest, meaning: determine the maintainers; send an email to the maintainers; have the maintainers reject/approve the account request. After that, mango should send an email to RT3 to have accounts team review the request and some link to easily create the account when needed.

• Combined with streamlining the accounts process, mango should be able to act as a self-service. Users should be able to login securely (this is not just SSL), and change some details (not everything!).

• Proposed by OlavVitters. Not sure if I want/can mentor this. I have a pretty good idea about a possible design, but students are welcome to propose something.

• OlavVitters will likely question students about security knowledge.

• Make Evolution use Seahorse widgets for encryption and key selection (mentor: Adam Schreiber and SrinivasaRagavan)

• Benefits: Tighter more consistent interface.

• Requirements: C programming

• Add encryption details to contacts using seahorse's DBus interface

• FoieGras - a new documentation editor (Mentor: DonScorgie)

• Benefits: Documentation writers rejoice. ProjectMallard is moved one step closer to reality

• Requirements: Python, XML (or a willingness to learn these)

• Project Mallard is already underway in various forms (see ProjectMallard for more details). One big component still missing is a new documentation editor. Currently, this is only a plan and some requirements (ProjectMallard/FoieGras). Taking on this project would involve working within these requirements to produce an initial version of FoieGras and possibly extend this to add more features / create a much firmer plan for how the project would move forward

• Questions can be asked in IRC channel #docs on irc.gimp.net or email.

• Better keyboard layout control (mentor: SergeyUdaltsov)

• Benefits: multilingual users, and users working in a country foreign to them, get easier control over their keyboard.

• Requirements: Fixing this has ramifications in X11, which imposes limitations on GNOME.

• Explanation: The keyboard capplet needs redesign to make it more usable. It most probably would require introducing changes in Xorg configuration database (xkeyboard-config). X11/Xorg limit users to 4 layouts, which imposes a distinction between "installed" and "loaded" layouts which is artificial to users. It also has a strange concept of "layouts" vs "groups" which are also confusing. It would be good to get rid of both of these limitations as part of this project.

• Note that the keyboard capplet might also get touched by the "Brave new X11 world" idea in its "dynamic input" secion.

• New geometry manager for GTK+ (Mentor: FedericoMenaQuintero)

• Benefits: support "minimum/natural" sizing in GTK+ and height-for-width geometry management

• Skill level: medium/advanced

• Requirements: proficiency with C and GTK+. Student must have written at least one GTK+ widget from scratch.

• Summary:: The GTK+ toolkit, as of version 2.10.x, supports a very simple scheme for geometry management. Widgets get asked how much space they want to occupy, and then they are given (in most cases) just that much space or a bit more. This is GTK+'s "size_request / size_allocate" scheme. While this is adequate for many applications, a good number of them do need a more sophisticated scheme for geometry management.

• The main enhancements that are needed are these:

  • Expand the sizing model to have "minimum size" and "natural size", instead of just "minimum size" (size_request).
  • Add height-for-width and width-for-height sizing. This is so that we can have text widgets such as labels that auto-wrap correctly: GTK+ would ask a label, "how tall would you be if you were 200 pixels wide?", the label would wrap its text to that width, and answer back with the required height to fit all the text.

  • Modify some of the stock widgets (especially GtkLabel) and the basic layout containers (GtkBox, GtkTable) to support this kind of geometry management.

• You can base your work on what has been done for the Mugshot project.

• In the end, you will be able to close these GTK+ bugs:

  • #104188 - add height-for-width geometry management

  • #101968 - height-for-width wrapping for GtkLabel

• Goals:

  • Implement core support for minimum/natural sizing.
  • Implement core support for height-for-width and width-for-height.

  • Implement height-for-width support in GtkLabel.

  • Implement minimum/natural sizing in GtkBox and GtkTable.

  • Do this without breaking the GTK+ ABI/API, by using GTypeInterface.
  • Implement a test suite for the geometry management code.
  • Be no more than 5% slower than the current geometry manager, regardless of whether old-style or new-style widgets are being used.

• Bonus points for the following:

  • Implement minimum/natural sizing in GtkTreeView.

• Lockdown support for Nautilus and GtkFileChooser (Mentor: FedericoMenaQuintero)

• Benefits: make Nautilus and GtkFileChooser more friendly to big installations by letting system administrators define items to be shown in users' desktops, and by letting admins constrain users to a particular subset of the file system.

• Requirements: proficiency with C and GDB.

• Summary: System administrators who set up large installations for hundreds or thousands or users (universities, governments, companies) need to be able to pre-configure the desktops for those users on a large scale, and to limit what the users can do in certain ways.

• For Nautilus, which acts as the main desktop shell and file manager, system administrators need to be able to do at least two things:
  • Define items which will be shown on users' desktops, such as links to common web sites, launchers for programs, or links to commonly-used files such as forms or reference material.
  • Constrain the view of the file system to certain parts. Users on thin clients don't need to be able to look outside their own $HOME and certain special directories, like network shares or removable volumes.
  The file chooser in GTK+ has similar requirements.

• Goals:

  • For each user profile, be able to pre-define items which will show up in users' desktops,
  • For each user profile, be able to pre-define which parts of the file system the user may visit.

  • For each user profile, be able to pre-define "Places" for GtkFileChooser's shortcuts pane and for the Places sidebar in Nautilus.

• Metacity compositor integration (mentor: ThomasThurman)

• Benefits: everything looks prettier

• Requirements: C, basic X, willingness to research xgl

• Explanation: Metacity has a compositor that is half-integrated but not turned on at compile time. This project involves making it good enough that it can be turned on, which will make everyone happy.

2.2. Alternatives

• Revision Control for Tomboy Notes (mentor: SandyArmstrong)

• Benefits: Simple and easy to use note-taking for the paranoid user.

• Requirements: C# programming, basic experience in a version control system like cvs/svn/bzr/git/, etc.

• Notice that Tomboy doesn't have a "save" button. If your solution adds a "commit" button, you might be on the wrong track.
• Does your solution involve putting note files in a svn (or whatever) repository? How does the user manage that repository? Is version control optional?
• Really, we're interested in hearing peoples' ideas on how to achieve this and still have an awesome friendly simple Tomboy. But it seems tricky and we'll probably be hard to convince.
• It might be cool to integrate this into an "undelete" or "wastebasket" feature (currently when you "delete" a note it is just moved into a subfolder, but you have to recover manually)

• Coding the next version of art.gnome.org (mentor: ThomasWood)

• Benefits: Users love cool artwork - users love web2.0 - lets combine the two

• Requirements: Need to know PHP and MySQL.

• More Information here: http://live.gnome.org/GnomeArt/Ago3/Ideas

  • I think there are open bugs on making installing themes easier. Those would go well with this.
    • Yes, a lot of bugs (not necessary installing themes) will be solved with AGO3 --Drom

• Intelligent Main Menu (mentor: ChristianKellner)

• Benefits: Having a very smart main menu will reduce the clicks needed to open programs dramatically

• Requirements: C Programming (GObject), maybe some knowledge in various datamining, KI techniques

• That project is more a general experiment on what could be done when AI-related techniques meet the desktop. More a study what could be done with AI-related techniques and if it makes sense. So it's very unlikely that the outcome here might directly land into GNOME 2.20 or even the near future but more about exploring some new fields and ways.

• This is about making something like the Gnome Main Menu use various techniques to better find out what applications (recent files, peoples etc) it should display in its correspoding "tab". In other words its trying to guess what apps you are most likely to launch right now. I was thinking of using good mix (weighted mix) of Association Rule Discovery[1] (Always when someone started app X then he has also started Y; or the other way around like: when firefox was already running, it never got started from the menu again because the user used tabs), most or least frequently used apps and a chronologial based heuristic (gaim got always started right login but never again).

• [1] http://en.wikipedia.org/wiki/Association_rule

• Be carefull with adaptive menues, some users react negatively to them. [2]

• [2] http://portal.acm.org/citation.cfm?doid=503376.503406

• Make Epiphany browser use GTK for web widgets (ie: buttons, check boxes, etc.) (mentor: ?)

• Benefits: A prettier-looking web browser with better gnome integration instead of the ugly web widgets that it has now.

• Requirements: Some intensive re-writing of the Gecko engine.

• (Couldn't trying gtk+ webkit be added here aswell... or somewhere else?)

• This idea is nice (from the user point of view) but it's really hard to achieve. Keep this in mind -- LucasRocha

• This is not an appropriate project for SoC; it is only needed to fix a few gecko bugs. See upstream bug -- chpe

• Encrypted Tomboy Notes (mentor: SandyArmstrong)

• Benefits: Simple and easy to use secure note taking.

• Requirements: C# Programming, basic understanding of encryption/signing, a vision of note encryption that doesn't disrupt a user's "flow".

• Please check the mailing list archives and read bug #417316. Understand what's been attempted already.
• Consider if/when it makes sense to use gnome-keyring. What if I want to email an encrypted note to a friend, or synchronize it with my laptop's Tomboy notes? Does your proposal cover the common use cases?
• Encrypting a note is not that challenging. Your proposal will need to convince us that you understand how to make this feature as stream-lined and easy-to-use as possible. Encypting/decrypting notes should be as simple as everything else in Tomboy. And the UI shouldn't get in my way if I never use that feature.
• Encryption can probably be done by using the DBus interface of seahorse

• Seahorse developers may already be working on something similar. Find out!

• Polish Nautilus list view

• Benefits: Nautilus is better!

• Requirements: C, probably.

• Nautilus list view has quite a few bugs open, particularly relating to items in expanded subfolders (Scripts won't run on them, pattern select won't work on them and so on)

• Commandline interpreter for the Nemiver Debugger (mentor: DodjiSeketeli, JonathonJongsma)

• Benefits: Make a really great debugger for GNOME developers. Currently GNOME has a relative lack of high-quality developer tools.

• Requirements: C++ programming, some gtkmm

• The Nemiver debugger aims to provide a first-class debugger for use in developing GNOME applications. Adding a command-line interpreter would allow experienced users to have all of the benefits of a graphical debugger (e.g. seeing full highlighted source code, integration with the desktop environment) while still maintaining the efficiency of using gdb on the commandline. The idea is to allow users to, for example, quickly set a breakpoint using "b functionname" without having to open a file and select the line to break at with the mouse. The command line interpreter would not implement every command supported by gdb, just the most common ones.

• Possible alternate ideas involving Nemiver: Create a memory inspector, investigate adding a new debugger backend for e.g. debugging python programs (Nemiver is designed with a pluggable infrastructure so it can use multiple debugger backends)

• Desktop Search Engine integration with Evolution (Mentor: ?)

• Benefits: Faster and more accurate Evolution searches for Beagle/Tracker/etc. users. Tighter desktop integration, reduced redundancy in indexes.

• Requirements: C, knowledge of Evolution/Gtk is ideal, but can be learned.

• Desktop search engines like Beagle index Evolution Mail messages (as well as some other Evolution data) and Evolution could benefit by querying Beagle (if it is running) for faster search results, especially in full-text search situations.

2.3. Underground

• Improve integration of Zeroconf technology into GNOME (mentor: Lennart Poettering, others?)

• Benefits: Make it easier for non-technical people to use networked stuff.

• Requirements: C programming, a good idea what Zeroconf is about

• This is a bag of small things: notify the user about name conflicts with libnotify; change the mDNS host name depending on the user logged in; make NetworkManager a little bit more Avahi-aware (i.e. replace their IPv4LL implementation with avahi-autoipd; and the previous two items should probably done in NetworkManager as well); a small capplet for configure browse domains; support domains in gnome-vfs/nautilus; add service browsing capabilities through avahi-ui to every single GNOME module that is part of the GNOME Desktop set of packages and where Zeroconf makes sense, such as the proxy configuration capplet, evolution mail erver configuration, various gnome applets, totem streaming server selection and more.

• This needs some cooperation from people from all the different GNOME modules that are touched by this

• This item is also listed on Avahi's GSoC page: http://avahi.org/wiki/GoogleSummerOfCode (together with a few other ideas which are not directly related to GNOME)

• Make some core GNOME modules sexier (mentor: VincentUntz, others?)

• Benefits: Better user experience

• Requirements: C/GTK+ programming, and a bit of cairo

• It's not about adding useless effects, but some little changes that improves the user experience
• Here are some examples of what could be done (mainly gnome-panel, but that's only because those ideas are on the top of my head): nicer feedback when clicking on a launcher in the panel, panels nicely sliding in/out when logging in/out instead of just appearing on the screen, nice animation when moving an expanded panel to another screen border, nice animation when a panel goes from expanded state to non-expanded state, fade-in of an icon when it appears on the desktop (instead of just appearing out of nowhere)
• This doesn't have to be only one SoC project (if the various students working on this task don't work on the same modules, eg)

• Face recognition feature for F-spot (mentor: StephaneDelcroix)

• Benefits: Give F-spot the ability to automatically find images containing faces of certain persons.

• Requirements: C# programming, knowledge of image recognition algorithms, classification algorithms, etc.

• Explanation : The ultimate goal of the project would be to enable smart-tagging of pictures with names of the people that are on the picture. This would be done automagically by F-spot, based on initial user input. The user would only give the name of the person that F-spot has found on the image. Since it is a complex project it is obvious that only a part of it could be done within the SoC period, so it is important to specify the goals to achieve during the SoC.

• Write an application like photo booth or add webcam support with the same features to F-spot. (mentor: RaphaelSlinckx)

• Benefits: At the moment there are many little program to handle webcams, but there is nothing as good (and as funny) as photo booth.

• Requirements : V4L/GTK+ C# programming, or simply C if it has to be an application outside F-spot. Some image processing algorithms knowledge is also needed.

• Explanation : The goal is very simple. Make a software like photo booth to take pictures from webcams that would finally be easy-to-use and funny-to-use. Features like integration with evolution could also be implemented.

• RaphaelSlinckx: I can happily mentor this, as i started myself a hacked together photo booth: http://raphael.slinckx.net/blog/2007-03-12/lets-take-pictures

• General New Panel Stuff (mentor: ?)

• Benefits: The GNOME panel is one of the most visible areas of GNOME. Improvements here would be visible and would get good recognition of the state of GNOME.

• Requirements : C/Gtk programming

• Explanation : There has been previous work on improving the panel. This project would aim to bring the improvements together as a new GNOME panel, breaking from the old code base. See the following for more info

  • http://live.gnome.org/SummerOfCode2006/Ideas (libgnome-applet)

  • AppletsRevisited

  • I'm not sure totally killing the old code base is the way to go... It'd be better to merge the work Ryan has done with the current code, so we don't lose years of bug fixing. -- VincentUntz

• Add D-Bus plugin/extensions capability to GNOME apps. (mentor: ?)

• Benefits : Plugins and extensions would be instantly language neutral, so authors could use whatever they like. GNOME apps need only concentrate on getting *one* API good and complete. This together should result in both more, and higher quality extensions. It would also instantly add external scripting abilities to the app, that can be used outside of the plugins.

• Requirements : C, Gtk and D-Bus programming probably.

• Explanation : Today many GNOME applications, like Gedit, Nautilus, Epiphany and others have extensions/plugins. What languages are supported is totally in the hands of both if someone took the time to implement it, and if it's not considered "bloat". Usually it's a mechanism where some file gets loaded, and inside, a plugin is supposed to register itself in one way or the other. I propose that instead, executable files marked as D-Bus scripts (in Gedit this would be a new loader, for instance) are just executed and forgotten by the app. It's then up to this executable, which could be Haskell or Ruby or Smalltalk or C or Python or whatever, to connect to the app via D-Bus and register that way, and start talking. At the same time, any program could be started by the user or any other trigger, connect to an app and use *the same API* to script and control the app (this will also help testing of plugins).

• The mission would be :

  • Pick any GNOME app that could use this, and
  • Export at least a basic D-Bus API, possibly based on existing plugin structure,
  • Make the app understand and load these new scripts with fire-and-forget,
  • Move some existing plugins to this new structure to verify that it's working and is sane to use.

• DeskbarApplet refactoring and fixing (mentor: RaphaelSlinckx)

• Benefits: Deskbar currently has unfixable flaws preventing some cool ideas to see the light. It has also become very hard to maintain because of the successive layers of fixing and patching

• Requirements: Knowledge of python and the gtk/gnome python bindings. Knowledge of the general concept behind deskbar is also a plus.

• There are several ideas that we want to add to deskbar that require deep architectural changes, ideally a heavy refactoring starting from the base code and removing all the cruft. After that we can start implementing the new feature (see links below) and it will be much more maintainable. Focus will be placed on memory consumption, speed of startup, non-blocking UI, giving more power to the handler and possibly work around all the focus bugs we are faced now. The development will happen in a separate branch and should be ready with no major regressions by the 2.20 timeframe. The deskbar team will assist with experience and guidance the student willing to undertake this task.
• Ideally deskbar would be split into core and UI. The core can stay in python, and the UI could be rewritten in C to be embeddable by any application. They would communicate with dbus for example. The UI in the current applet form is very unstable due to the way gtk widget handle focus. This cause an enormous amount of hacks to behave with various window managers and stuff. Ideally the match list would be in the same window as the search entry, everything being presented as a popup window or similar.
• A rough brain dump of tasks that would largely help us:
  • Strip out deskbar to its bare minimum removing the hacks and keeping the good concepts
  • Design a new plugin architecture allowing both blocking and non-blocking plugins to be written.
  • Optimize the startup time and the memory consumption by indexing some stuff in the background instead of the startup, looking at how quicksilver on macosx works.
  • Allow for a more versatile UI to be defined in terms of object-action pairs instead of only actions (for example an email is an object and 'send an email to' or 'open vcard' are different actions based on this object, again a la quicksilver)
  • Evaluate the possibility of adopting the gnome-launch-box UI instead or besides of the panel applet
  • Create a dbus api to separate deskbar UI's from the core
  • Keep in mind a way to use deskbar in an embedded way, example include gimmie, or the new slab menu by novell. This requires the UI of deskbar to be presented as a regular widget, while talking with the core over dbus for example. If deskbar stays in python this limits us to python as embedding language, if we write deskbar UI in C, then we can embed it in every UI through bindings.

• DeskbarApplet/Ideas

• DeskbarApplet/Design

• http://quicksilver.blacktree.com/

• http://developer.imendio.com/projects/gnome-launch-box

• GTK+/GNOME interface to Bugzilla (mentor: ?)

• Benefits: Improve the user experience of bugzilla users (ie, our contributors, but also contributors to other projects using bugzilla)

• Requirements: C or python programming, knowledge of bugzilla

• Note that this probably requires the xml-rpc extension to bugzilla, and discussion with our bugmasters would be needed
• The XML-RPC in bgo cannot be used for this. Not even upstreams XML-RPC is good enough in the current state; suggest wait for Bugzilla 3.2/3.4.

• Note: Such a tool is already in development: http://conseil.fritalk.com/ .

• Make the Users control panel be able to control LDAP users (mentor: ?)

• Benefits: Make life easier for large deployments

• Requirements: C/Perl programming

• See Glockenspiel for more information

• Implement SANE GnomeScan Backend using HAL probe (mentor: ?)

• Benefits: Handle hotplug and buttons. Provide post processing (OCR).

• Requirements: C/GObject programming

• See GnomeScan/Spec for more details.

• Integrate Seahorse with Tracker/Beagle (mentor: Adam Schreiber and someone from Tracker/Beagle)

• Benefits: Enhance information found about people or email addresses (first class objects) that are searched for.

• Requirements: Learn DBus message passing (easy), C programming ability

• The end result of this project may include creating additional widgets for libcryptui and inserting them into search results.

  • This probably doesn't need a mentor from Beagle/Tracker, as both have pretty public and well documented API's. Beagle even has a wiki page devoted to client development.

• wouldn't it make more sense to integrate seahorse with the evolution adressbook very tightly? (like gaim-evolution)

• Merge GTK+ HTML widgets into a unified widget (mentor: ?)

• Benefits : This would help not only applications who use HTML for display but also developers since they only have to choose 1 HTML widget, not two, three, ...

• Requirements : C and GNOME developer libs

• Explanation : GNOME as of today have two widgets that can handle HTML: GTKHTML2 and GTKHTML3. Outside GNOME there is mozembed and webkit (GTK+ port currently under development). It would really be great if the feature sets of GTKHTML 2 and 3 can be merged into a GTKHTML 4. This will help the maintainers to only have one widget to maintain and improve and of course having one HTML widget choose from would be nice.

• Checkbox/TODO/Tasks Notes in Tomboy (mentor: SandyArmstrong)

• Benefits: Simple and easy to use task management within your notes.

• Requirements: C# programming, GTK+ experience would help a lot.

• Please check the mailing list archives and CheckboxesMockupPage to see what some other people have suggested.

• Does it make sense to integrate this with tasks in Evolution? If so, how easy would it be to have a non-Evolution backend as well?
• Your approach should fit in to the way people use Tomboy. If it is a single note with a bunch of checkboxes, then it's not Tomboy, and people should stick with Ross Burton's excellent Tasks program. Can you think of a great way to make tasks a part of Tomboy?

• Maybe it makes sense to integrate this into the NoteOfTheDay plugin? Maybe you can put task lists in any note, but there is one note you can open that shows all of your tasks? What do you envision?

• Libisofs improvements - HFS, HFS+, eltorito, ... (Mentor: ? ; Advisor: MarioDanic)

• Benefits: Getting one step closer to getting rid of using mkisofs in gnome applications.

• Requirements: C

• This project requires a dedicated student willing to spend a lot of time reading and understanding specifications.

• Project page: http://libburnia.pykix.org

• Voice recognition applet to control desktop (NickolayShmyrev)

• Benefits: Bring incredible technology to GNOME desktop

• Requirements: C

• We'll define a set of actions like switching from one desktop to another, minimizing the window and so on, then we'll record and process speech database and will embed it into GNOME. CMU Sphinx open source tools will be used.

• Linux Desktop Testing Project (mentor: NagappanAlagappan, VeerapuramVaradhan)

• Benefits: Automation testing of applications like nautilus

• Requirements: Python programming

• Nautilus automated testing using LDTP

• Adding LDTP recording functionality to the code base

• Evolution Data Server backend for Google Calendar (Mentor: HarishKrishnaswamy, ChenthillPalanisamy)

• Benefits: Connectivity to Google Calendar from your favorite client on the GNOME desktop

• Requirements: C/GObject programming, knowledge of EDS code (desirable).

• Create a Google Calendar backend that allows reading and writing into Google Calendar through the GData interface. The Evolution Brainread component also has some reference code on Evolution interacting with an RSS feed.

• Touchpad support for mouse preferences capplet (Mentor: ?)

• Benefits: add GUI support for the vast number of configurable options in the synaptics touchpad driver

• Skill level: medium

• Requirements: C, Gtk programming (for the GUI).

• Note: there already exists an option in the Synaptics driver for "run-time configuration using shared memory". Use of this interface might be appropriate or possibly another interface can be used.

• Note: There also exists a gui gsynaptics which could be used as a base.

• Tracker-Beagle integration with Rhythmbox (Mentor: James Livingston)

• Benefits: Make Rhythmbox nicer to use, as it will automatically detect your music and share metadata

• Requirements: C, some knowledge of database concepts (SQL not necessary) would be useful

• Using Tracker/Beagle to import tracks into Rhythmbox would allow us to get rid of the horrible first-run druid, and let us expose our metadata to other applications. It would include some extra things like synchronising keywords, or using Tracker/Beagle for searches, to add awesome useful things. Questions can be directed to the IRC channel #rhythmbox on irc.gimp.net.

2.4. New/not-triaged

• Enhanced Nautilus Desktop managment

• Benefits: Makes the desktop cleaner and increases the usability

• Requirements: C, some knowledge of nautilus internals, GTK

• To develop a new concept of desktop view, dividing the desktop in functional areas. One area would have the devices icons, another the places icons, another will be the regular desktop. Maybe other ideas.

• Multiple rows system tray

• Benefits: Saves panel space when the heigth of the panel is doubled (or more)

• Requirements: C, GTK

• Use multiple rows to display the system tray icons.

• Create a quick launch icon container (multi row)

• Benefits: Add the possibility to limit the maximum icon size within the container

• Requirements: C, GTK

• Create a quick launch icon container (panel applet) with the possibility to limit the max (and the min) size of the icons contained and to use multiple rows to display the icons.

3. Other ideas

3.1. For GNOME-related projects

Unless otherwise noted, you may make proposals related to these projects with GNOME as your mentor organization.

• GStreamer

• Avahi

• Beagle (The Beagle project would be your mentor organization, not GNOME)

3.2. For GNOME from previous Summers of Code editions

• SummerOfCode2005

• 2006