Monthly Archives: May 2014

GNOME Asia 2014

I spent last weekend in Beijing attending GNOME Asia 2014; yeah, long trip from Europe just for 3 days, but it was totally worth it. The worst part of it was of course fighting jet lag when I arrived, and fighting it again 3 days later when I came back to Spain 🙂 The conference was really well organized [1], so kudos to all the local team!

After a quick sleep on Friday morning, I attended the development and documentation training sessions that Kat, André and Dave gave. They were quite interesting, especially since I’m not involved in the real user documentation that GNOME provides. I have to say that these guys do an amazing job, not only teaching during conferences, but also through the whole year.

There are, from my point of view, two main ways of learning new things:

  • The ‘engineer’ way: Learning things as you need them, what you would do when you start writing an application and looking for examples of how to do what you want to do (autotools, anyone?). It is a very ‘engineer’ way, as you pick black boxes that you’ll use to build something bigger, while not fully understanding what the black box does inside.
  • The ‘scientific’ way: When you learn something in order to fully understand it and be able to teach others. This approach takes a lot longer, as you need to make sure that everything you learn is accurate and you end up questioning the things that are not clear enough. Learning stuff to teach others is actually what you do in University; you’re learning things that will afterwards need to be explained in an exam to someone who knows more about the subject than you do.

Sure, both ways have their ups and downs, but if you want to write software you need to be able to switch between those two mindsets constantly. You’ll use the engineer way when reading API docs, looking for the bits and pieces that you need to build your stuff. You’ll use the ‘scientific’ way when you need to start learning a new technology, or when you need more detail on how to do things. While the API docs are taken care of by the library developers, it is the documentation team the one making sure that user guides, tutorials, and other developer resources are kept up to date, which are definitely some of the toughest and most important tasks done to help newcomers and other developers. So go on, go learn GNOME technologies and teach others, join the documentation team! 😉

GNOME Asia is not a usual conference. If you have attended a Desktop Summit, GUADEC or FOSDEM before, all those conferences are built by developers and for developers. The focus of those conferences is usually not (explicitly) to attract newcomers, but instead to be a show of the latest and shiniest things happening in the projects. Of course we also had part of that in Beijing, say Lennart’s talk about the status of systemd or Allan’s talk about application bundles. Those both were very good talks, but likely too specific for most of the audience. Instead, I chose to talk about something more basic, focused on attracting newcomers wanting to write applications, and so I gave an Introduction to D-Bus talk, including some examples. It is the same talk I gave last year in GUADEC-ES, but in English this time (my Mandarin is not good enough).

I would like to thank the GNOME Foundation for sponsoring the flight to Beijing, and of course to all the local team who, as I already said, did an amazing job.


[1] …except for the tea-less tea-breaks 😉

Profiles in Devhelp

I’m at the GNOME Development Experience Hackfest in Berlin, and one of the things that I wanted to target during these days was to keep on looking at how we can enable different profiles in Devhelp.


As you probably know, Devhelp will show you the documentation of libraries installed in your system (usually only if you have the -devel or -docs package of the library installed). While this is already enough for most users, there is also the case where a developer wants to target a different version (older or newer) of the library than the one installed in the system.

A typical case for this is developing applications using GNOME’s jhbuild infrastructure, targeted either to a given GNOME release or to git master of the involved modules. In this case, if you want to use new methods of let’s say GTK+, you usually end up needing to fire up a web browser and looking for the latest GTK+ documentation either in or in your jhbuild’s ${prefix}/share/gtk-doc/html directory.

In order to avoid this, I’m prototyping some ideas to let the users switch between different profiles, e.g.:

  • The ‘local’ profile, which is equivalent to what Devhelp currently shows.
  • A user-defined ‘jhbuild’ profile, which could point to the install prefix of the jhbuild setup.
  • Other user-defined profiles, which could point to other prefixes where the user has installed the newer (or older) libraries and their documentation.
  • Profiles for each new GNOME release, e.g. 3.12, which could get downloaded from as a tarball containing all documentation for a given release.

The most challenging case is probably the last one, given that it would require some extra work in the website in order to make sure the documentation tarball is generated and published in every new release, plus of course client-side management of these downloaded profiles in Devhelp.

For now this is just a basic set of ideas, the final result may or may not be similar; we’re of course open to suggestions!