gnome 3.8 is on track to be released on time as usual (the release candidate will be out later today): it’s a great incremental release with improvements all over the place, but I’ll let the release notes speak.
For my own part, I put my fingers here and there either making patches or trying to help (annoy?) people doing the real hard work with reviews and suggestions.
Clocks has matured from a prototype to a real app and in this cycle. It turns out that while from the code point of view a clocks app is really a small application (some even think trivial and a waste of resources better spent improving other aspect of gnome) it is actually quite challanging to design and decide how all the small details should work, since the user expectations for such a familiar object are very high. It has also been a good way to experiment with the new design patterns and the new widgets (like the ones in libgd). There are surely many things to improve in the next iteration, a particularly sore point that I am a bit ashamed to not have fixed yet it is the persistence of alarms when the app is not running (or even when the system is suspended), but today’s bug is tomorrows chance to get involved!
The application went through a full rewrite to address many of the issues found in the first implementation. I opted for a rewrite in vala because it is probably the more mature technology if you want to write a GObject based app today and you are a bit sick of writing C boilerplate, but at the same time you need to pull some tricks to call some C code and libraries without proper introspection support. However I think the choice of the language is a secondary aspect of the rewrite compared to the use of some good practices I tried to adopt in the new code (use of many of the new prototype widgets in libgd, use of .ui files, use of GLib resources, use of GLib based library calls for everything, etc). Clocks is small enough I do not exclude to try a JS rewrite even if just as an exercise to see how the platform is maturing. In this regard I am really excited to see Giovanni’s work on defining a good platform for JS apps… I have some opinions in that regard (also due to the fact that I am back doing quite a bit of JS at work), but that’s probably best saved for another post.
Gedit has been ported to GtkApplication: from the user point of view this mostly means that when run within gnome-shell you will see an appmenu (while you will get the usual menu when running on a WM that does not support that). However under the hood this meant quite a lot of code to rework: gedit makes use of many exotic features of GtkApplication, like handling stdin (you have now to use cat file.txt | gedit – , note the dash at the end) and support for blocking the terminal in order to be able to use EDITOR=gedit for git commits etc).
We also ported gedit plugin system to use Python 3, in compliance to a gnome wide goal. This has the unfortunate side effect of breaking third party plugins once again, but I think it is a step worth taking in the long term and the sooner the better: if you have to port your plugin you just need to specify “loader=python3” in the .plugin file and make sure the code is valid python 3, gedit’s API did not change.
GtkSourceView has seen lots of work on the completion framework thanks to the Sebastien Wilmet, his blog has all the interesting details.
Baobab saw a few of incremental improvements after the major rework of 3.6, including a classy animation from the summary to the results page thanks to the wonders of libgd. With regard to baobab, if you are looking for a challenging, but relatively small and fun project, it would be great to see someone step up and implement animated charts (Stefano had a prototype) and rework the treemap to use the squarified algorithm… It would probably make for a good GSOC project, though you would have to find a mentor since I do not think to have time to do that this year (unless a really strong and independent candidate shows up).