Montreal: lets improve the GNOME development story


me and more people from Codethink are going to be in Montreal to propose what we think can be the solution to improve the build and the development story of GNOME OS : Baserock

The project is still in early stage of development, so the idea at Montreal is to have tech discussions to work out how baserock can best help on the deployment of GNOME OS.

Take a look to the overview Baserock page for more info.

Thanks to Codethink to sponsor our travel here, and also all the other sponsors to make this event possible:

Stay tunned!

GNOME 3 is here!

I’m happy, GNOME 3.0 is out!

I still remember when in 2009 I heard about a plan to make the next GNOME version.
I wanted to contribute and I met some great people that guide me on the best way to help in the effort, so I started to work in the Streamlining of the Platform part, trying to remove all the deprecated stuff. Also I started to work with the Bugsquad team, on GnomeGoals and then in GTK+3.

And now GNOME 3.0 is finally here! 🙂 Thanks to all the people that made this release possible! You all rock!

If you are in Manchester, come to MadLab this Sunday at 14:00 for the GNOME 3 Launch Party!

And, of course:


Use upstream gettext instead the glib one

Some people asked me about this, so here a fast tutorial:
Replace this in your


with this:


You can see an example in this commit: [1]

Now the theory: gettext has two different utilities: autopoint and gettextize. Here the different purposes of these programs:

  • autopoint [2] Copies the gettext infrastructure that has been omitted from version control.
  • gettextize [3] The `gettextize’ program is an interactive tool that helps the maintainer of a package internationalized through GNU `gettext’. … As a migration tool, for upgrading the GNU `gettext’ support in a package from a previous to a newer version of GNU `gettext’.

So, you should only use autopoint in your file. Only the maintainer should call the gettextize program.
Fortunately, autopoint is automatically called in both and autoreconf, so no need to change your file.

Note that autopoint needs the AM_GNU_GETTEXT_VERSION() macro to know the version of gettext files you want tou use, because it copies the infrastructure files belonging to this version into the package. ie, AM_GNU_GETTEXT_VERSION([0.17]) means exactly 0.17, not 0.17 and above.

Why we use glib-gettextize then? Well, as far as I know It’s mainly for historical reasons: autopoint was not added until version 0.11 of gettext. However, GNOME did not require gettext version 0.11 those days, so it would had been premature to rely on that script. That is not a problem anymore.

There is also a bug to deprecate the Glib gettext macros: [4]


Flattr this


Flight booked and registered on GUADEC 2010 page. Here we go!

I’ll also attend the Hispano GNOME Hispano meeting some days before  (22-23 July), so It’ll be a very GNOMy weeks 🙂

I’d like to say a BIG thank you to the GNOME Foundation for sponsor my trip to the GUADEC, I’ll try to maximize the time as far as I can.

I’m very happy to get the chance to get in touch with the people I’ve been working all the year,

See you all there!!

Sponsored by GNOME Foundation

GTK+ and GSoC

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!

GnomeGoals Status Report

I’d like to share the status of some GnomeGoals, as some of them have been recently completed:

RemoveGnomeOpenGnomeHelp: completed!

DropLibsexy: completed!

RemoveLibGladeUseGtkBuilder: only remaining: sound-juicer. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

CleanupGTKIncludes: mostly complete. Remaining: gnome-disk-utility . Also, It’s needed to check gtk-sharp, gnome-desktop-sharp and some GNOME external dependencies.

CorrectDesktopFiles: mostly completed. I’ve been filling some bugs and I think this GnomeGoal is complete now. Anyway, please, check your module an update the wiki page. Updated automatical stats can be found here.

UseGseal: In progress. Some modules was already ported to use accessor functions instead direct access to prepare to GTK+3 transition. The GTK+ api to make the port is mostly complete now, but there still are some corner cases. Please, start porting you module ASAP and fille bugs agains GTK+ if you need some new api.

AddGObjectIntrospectionSupport: In progress. You can take a look to the modules marked as ‘done’ to help you to add introspection support inside your module. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

RemoveDeprecatedSymbols/Glib: Mostly complete. Anyway take a look on this as some new symbols can be deprecated in each cycle. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

RemoveDeprecatedSymbols/GTK+: Mostly complete. Anyway take a look on this as some new symbols can be deprecated in each cycle. Updated automatical stats can be found at Frédéric Péters’ 299 report [1]

As you can see, the status of the GnomeGoals is pretty good so congrats everyone!! 🙂


Improve performance: Use ->priv instead GET_PRIV() macros

Sure you already know this, but if someone don’t:

Maybe some of you have this in your *.c GObject files:


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 [1] 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, …


This work by Javier Jardón is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported.