I’d like to share some exciting new about GTK+ development.
In short: GTK+ master branch: Development towards 3.0 !!
Mathias Clasen has been merged the gtk-2-90 branch. This branch has been used to prepare a lot of the deprecation removal, etc, for 3.0.
So we have now:
- gtk-2-20: the usual stable branch
- gtk-2-22: special branch that will only pick up remaining accessors that are needed to make GTK+ 2.x users build with GSEAL and get them ready to work with 3.x (no new features)
- master: Development towards GTK+ 3.0 with new features
More information of the actual status of the GTK+ branches in this mail on gtk-devel-list.
Also, I’m very exciting to announce that I’ve been accepted in this year GSoC (you can see my application here), so I can help GTK+ devels in the GTK+3 transition tasks.
Thanks to the GNOME people for accept my application!
Also, thanks to GTK+ devels for their help (and their patience sometimes ;)), specially to Carlos Garnacho to be my mentor
The fun begins!
Sure you already know this, but if someone don’t:
Maybe some of you have this in your *.c GObject files:
#define GET_PRIV(obj) (G_TYPE_INSTANCE_GET_PRIVATE ((obj), MY_TYPE_OBJECT, MyObjectPriv))
And then you use this macro in all your functions to access the GObject private structure.
You shouldn’t do this.
Instead, declare a *priv member in public structure and then access private members with my_object->priv->var
Maybe you think the performance improvement is not a lot. Well, I applied a similar patch to giggle  and now the startup time is ~10 second faster when opening the evolution git repository.
So, I think it’s worth
Update: From Edward Hervey comments: Some of the benefits of use of G_TYPE_INSTANCE_GET_PRIVATE(): memory space gets allocated alongside your instance, avoids an extra alloc, memory is contiguous, …
Update: Before start working in a module, check that It’s not already deprecated (like CList or CTree): these modules will be removed in GTK+3 so the doc migration is not needed
One of the tasks to improve the GTK+/Glib docs maintenance is to convert the documentation from templates (*.sgml) files into source-comments. This is a easy tasks that everybody can do.
All the process is documented here: 
Here a step-by-step example to help new contributors
- Download GTK+ and gtk-doc source code:
git clone git://git.gnome.org/gtk-doc
git clone git://git.gnome.org/gtk+
- Execute gtk-doc script to convert the documentation
This creates a “src” directory containing “*.c” files with all the comments.
- Copy and paste them to the right place.
The section docs are best placed in the *.c file. Put them below the copyright header and the main includes (if there is no *.c file use the appropriate *.h file).
All other comment blocks should be put directly above the definition of the symbol.
For example, for
GtkAccelGroup, we’d move the comments from
- Remove the template file:
git rm docs/reference/gtk/tmpl/gtkaccelgroup.sgml
- Check that the documentation is correctly generated with:
then go with a browser to docs/reference/gtk/html
- Send a patch to bugzilla and make it block 599599 for GTK+ or 589775 for Glib documentation.
- Update the wiki page  to avoid duplicate work
When adding the source code comment, its a good opportunity to review it a bit. Have a look on spelling and style. Is it really giving a helpful explanation what the function does, etc. Also improve cross references. The gtk-doc syntax of the comments is described in the gtk-doc manual .
You can take a look to the gtkwidget.h  and gtkwidget.c  code as an example.
I’ve been working in GNOME3 “cleaning” tasks for some time and I’d like to share this mini-guide to make your library/application GNOME3 / GTK+3-compilant. The process is quite easy:
Don’t use deprecated libraries:
When you finish, use GNOME_MAINTAINER_MODE_DEFINES macro ( included in gnome-common ) in your configure.ac files, so you will be notified when you use a new deprecated symbol.
Also, take a look to the awesome Frederic Peters graphs to track the status of your module: http://www.gnome.org/~fpeters/299.html