So it looks like the 2.8.3 release went mostly ok. The 2.10.0 work definitely rocks and the wiki is really alive and cooking these days.
After 2.8.x I’ve spent most of my time running valgrind on GNOME and it’s looking good so far. A few leaks found and some other cases of bogus memory management fixed. I also started porting some pieces away from the deprecated widgets and doing general cleanups in various modules. There’s a lot of cruft all over the place that should be excised.
On the topic of header includes – we have tons of files that do things wrong here. It would be nice if the coding style guidelines for GNOME said something about this in my opinion.
The de-facto standard seems to be to:
- include <config.h> first in every C-file
- avoid having <config.h> in other headers
- start at the bottom of the stack when ordering includes
This gives something like what we see in GTK+:
#include <config.h>
#include <stdlib.h>
#include <string.h>
#include <glib.h>
#include <glib/gprintf.h>
#include <gobject/gvaluecollector.h>
#include "gtkalias.h"
#include "gtktreemodel.h"
#include "gtktreeview.h"
#include "gtktreeprivate.h"
#include "gtkmarshalers.h"
Also, I think it’s mostly agreed on that including the specific header you need from a library is better than to include the catch-all headers like <gtk/gtk.h>, <libgnome/libgnome.h>, <gnome.h> and so on.
It definitely makes it clearer what parts of a library is being used in the file at least, which is a good thing when trying to port to newer widgets later on.
The sparsing, valgrinding and cruft-excising tour is coming to a module near you real soon now ™
Update
Sven Neumann pointed out to me that using the specific headers was ok within a library but that the catch-all headers are the documented way to use GTK+ at least. Thanks for that clarification.
The point I tried to make was that there’s room for improvement when it comes to following *any* standard from what little I’ve seen in CVS.