Club Silencio

Some days ago lucasr sent an interesting mail to desktop-devel-list pointing out that some modules did not yet release a test version for the next GNOME and suggesting that if the reason was lack of manpower the current developers of the module should post a list of potential tasks in order to attrack new developers.

gedit was in the list that Lucas posted, but that was in part due to the fact that we were working on the gtksourceview 2 port and release was blocking on that. That said, lack of time and manpower is a real issue for gedit these days, so as promised to Lucas here is a list of tasks for gedit.

Note: I am restricting the list to the official gedit tarball, since our third party plugins community is more active than ever and new plugins pop up every day. Beside I am trying to list tasks that are a good fit for new developers, of a size big enough to make the challenge interesting, but without requiring an intimate knowledge of all gedit internals.

1. GtkPrint port: we would really love to dump the gnome-print dependency and use the gtk print support. However this is not a trivial task: among other things we want to keep printing asynchrounous and we want to keep our custom embedded print preview widget. Muntyan, of gtksourceview fame, has good code implementing print and print preview in his project and he’s willing to share it with us, but it needs quite a bit of refactoring to be used in gedit.
2. Use Gtk 2.12 features: the next version of gtk will have some very interesting features for gedit and we should take advantage of them. In particular:
   • GtkNotebook should now have all what it is required to replace a good chunk of GeditNotebook
   • Use the new tooltips API throughout the code and remove GeditTooltips
   • Add tooltips to some of the treeviews now that is possible (the tags plugin comes to my mind)
   • GtkRecent has seen some API deprecation and fixes and gedit should be updated
   • Take advantage of GRegex for things like filename filtering in the filebrowser pane
   • GtkBuilder (if it will meet our current needs)
   • probably other stuff I am now forgetting
3. Enhance the modeline plugin: the modeline plugin is the plugin that allows to set things like tab-indentation etc writing a special line at the top of the file. They should be extended to also allow to specify the language to use for highlighting and I would love to see the plugin extended to also support a .gedit-mode file put in the current dir so that you can drop it in the dir of your project to specify the codestyle to use. Such file should support setting different modes for different languages (e.g. the usual 8-spaces-long tabs for C and four-spaces indent for python)
4. Refactor DocumentSaver and DocumentLoader: this is a bit difficult since it touches pretty delicate parts of gedit and since it doesn’t led to any visible change, but I’d like to change the Saver and Loader objects to be abstract base classes plus some implementation classes (one for local files, one using gnome-vfs, etc) since this would make our life easier when gvfs will be released or if we want to make gnome-vfs optional
5. Project Ridley: I’d love to get rid of many of our dependencies and have an almost Gtk only version (GConf would still be there I guess and gnome-vfs is a bit hard to make optional, see point 4). Libgnome(ui) is used for very few things (like session-saving, which has a replacement in libegg). About gnome-print, see point 1 of the list.
6. Win32 port: ok, this is a bit hard and may in part depend on point 5, but it comes up from time to time so I thought I could mention it

There are probably other things I am forgetting and maybe nud or jessevdk have some more ideas and will blog about them.

There are also gtksourceview tasks, but those are for another time :) for now I’ll limit myself to say that help with new .lang files in gtksourceview 2 for your favourite programming language would be very appreciated.

Should you decide to pick up the challenge and try any of the above tasks, keep in mind the following advices:

• communicate: drop by on irc, let us know what you are doing, discuss your implementation strategy: given that the problem we are trying to solve is lack of developer manpower, I’d hate to see resources wasted in duplicated efforts.

• be pro-active: unfortunately, given the lack of time, we will not be able to mentor you as I would like, so you’ll have to be able to learn things by yourself and not stop at the first hurdle… If you don’t know C and gtk quite well, maybe this is not the project for you :-)

• ask questions: despite what I said in the point above, questions are always a good thing and I’ll try to answer as time permits

• be patient: as said lack of time is currently an issue for us, so we will not always be able to review your patches in a timely fashion. Beside, we are also very picky with regard to implementation details, so sometimes it may be a bit frustrating to get a patch ready to be committed, but good code always pays off in the end.