Gnome-utils 2.13.91 – Ain’t That a Brown Paper Bag?

The first second β-release of the Gnome-utils package is out!

Fixes for crashers, better error handling, font settings and much more!

Go get it!


Gnome-utils 2.13.90 had a glitch in the build system that resulted in the absence of the translations database in the package; thus I’ve just released the 2.13.91 version of gnome-utils, Ain’t that a brown paper bag, which fixes the glitch.


I’ve just updated the Recent Files and Bookmarks page on Gnome’s wiki: some (long due) clean ups and typo checking, but I’ve also added a porting guide, showing how to use the RecentManager and RecentChooser objects: addition, look up, display, sorting and filtering. If you are using the EggRecent code in your applications, go check it out.

As soon as Gnome 2.14 hits the mirrors, I’ll finally deprecate the EggRecent code – and won’t have to deal with the horrible EggRecentViewGtk widget anymore. Really, if there is a reason I wanted to implement the recenly used documents stuff, it surely must be to get rid of that code.


With the incoming release of Gnome 2.13.90, we are approaching the 2.14 version of Gnome. Now, features are frozen, and soon even changing the UI will require at least two approvals (one from the GUP and one from the release team); so, while we still have a full month for fixing bugs, I think it’s time for some little thinking and planning ahead about the next release cycle of gnome-utils.

The biggest job for the 2.15/2.16 cycle will be the cleaning up of the System Log Viewer. The code-base is a bit messy, but thanks to the great work of Vincent we’ve avoided the Design by Accretion Syndrome; still, even a white space consistency patch would be in order: some lines have a (horrid) three-space indentation, while some other have a tab indentation. So, I’d move everything to a tab-based indentation. The other “cosmetic” clean up is the removal of the dead and/or obsolete calls, the usage of a naming scheme for the classes and functions, and a switch to typed objects (e.g. boxed types and GObject-based types). I’ve already begun some attempt at cleaning up the code base, but this will most likely require to land in a new branch as soon as we release gnome-utils 2.14.

The other job is the implementation of a couple of transport methods for Dictionary, namely the HTTP-based transport, which should allow the connection to a web-based dictionary service; the file-based transport, which should allow the querying of locally available dictionaries; the StarDict transport, similar to the file-based one, but including a C parser for the StarDict format. Regarding this format, I’ve had a look at the C++ library and I seriously think that before releasing some software under an open source licence, a serious check on the code style should be in order; I don’t like C++, I think it’s inherently inefficient and messy, but something like this:

whitespace horror in lib.cpp

should really be closed source software – in order to avoid programmers throwing themselves out of the window after having had a look at it.

One more job would be the re-working of the gfloppy utility, with the addition of the ability to format every removable media (floppies, USB sticks, CD/DVD RW, etc). This will require some updates inside HAL – namely, the volume formatting and partitioning support. I think that, while floppies are becoming more and more rare these days, gfloppy might be reborn into something very useful again.

Finally, the last job for the 2.15/2.16 cycle should be the update of the Screenshot utility. First of all, I’d like to close bug #325708, but the whole bug list should be triaged and updated.

Obviously, I can’t promise that everything will be ready in time for 2.16. As always, patches that will make this happen faster are welcome.


The next release of gnome-utils, 2.13.90, will make libgdict adhere to the API/ABI freeze, even if it’s not part of the Gnome Developer Platform but only of the Desktop.

The freeze had been in effect since the last release (January 18th), and I planned not to change libgdict API; unfortunately, when writing the support for the document_font_name GConf key, which was introduced in Gnome 2.12 and that should be honoured by any application showing arbitrarily long texts to the user, I noticed that a call to gtk_widget_modify_font to a GtkContainer does not propagate to the containers’s children. The widget the Dictionary uses to display the text of the definitions is, in fact, a composite widget (a GtkVBox) as it needs to hold the text display and the find bar; the inner widgets are held inside a private structure, and are not visible to the outside.

If I wanted to work around this, I would have written something like this function inside the code of the libgdict users:

static void
gtk_container_modify_font_children (GtkContainer *container,
				    const gchar  *font_name)
  GList *children, *l;
  PangoFontDescription *font_desc;

  g_return_if_fail (GTK_IS_CONTAINER (container));

  font_desc = NULL;
  if (font_name)
      font_desc = pango_font_description_from_string (font_name);
      g_return_if_fail (font_desc != NULL);

  children = gtk_container_get_children (container);
  for (l = children; l != NULL; l = l->next)
        GtkWidget *widget = GTK_WIDGET (l->data);

	gtk_widget_modify_font (widget, font_desc);

  g_list_free (children);

  if (font_desc)
    pango_font_description_free (font_desc);

But it would not have worked; I wanted to change the font of the GtkTextView widget inside the GdictDefbox, while the function above would have changed font for all internal widgets – including the find pane.

Assigning a name to the GtkTextView widget, say “text-display”, by using the gtk_widget_set_name function, and changing the code of the inner loop to something like this:

  for (l = children; l != NULL; l = l->next)
        GtkWidget *widget = GTK_WIDGET (l->data);
	const gchar *name = gtk_widget_get_name (widget);

	if (strcmp (name, "text-display") == 0)
          gtk_widget_modify_font (widget, font_desc);

I would have avoided the API breakage inside libgdict – but I would also have created a performance bottleneck, since I transformed a constant time operation into a linear time one (from an assignment to a list walk) – plus, I don’t know what happens into gtk_widget_modify_font; also, I would have created a documentation issue, since I now would have to document the widget’s name and hope that nobody would ever have the urge to change the GdictDefbox font – at least, not after having had lunch.

Giving a name to the inner children of a composite widget is always a good practice – it makes handling these kind of situations easier; but between an hackish approach and a breakage of an API freeze, I would rather choose the latter. Hacks tend to get sticky, and you get a design by accretion if you let them stick around enough.

So, I opten for adding a new property to the GdictDefbox widget, called font-name, and its two accessor functions:

G_CONST_RETURN gchar *gdict_defbox_get_font_name (GdictDefbox *defbox);
void                  gdict_defbox_set_font_name (GdictDefbox *defbox,
						  const gchar *font_name);

Which are just proxies for the gtk_widget_modify_font function. Since nobody uses libgdict (it’s been out there only for the folks using Ubuntu or jhbuild), the breakage is really minimal; nevertheless, I feel a bit guilty for not having tested this stuff before, in time for the freeze.


It’s been snowing since yesterday morning, here in Milan. Waking up with 20 cm of snow and watching it grow has some sort of hypnotical beauty, which vanishes as soon as you realize that: two of the major national airports (one of which is the italian major international hub) are shut down; basically, all the roads to and from Milan are closed or soon-to-be (and all major news sources advice not to travel unless strictly necessary); also, one of the major railroads axis – the Milano-Roma – is basically cut off.

Two days worth of snow, and the entire northern Italy is cut off from the rest of the planet; so long for it being the economical centre of the nation.

Developement Trunk

Shamed by kris’ post about the state of Project Ridley stuff, I resumed the recent-files hacking after the gnome-utils/gnome-dictionary crazy run that occupied my nights in the last three months or so.

RecentManager and RecentChooser

I already did a review of the documentation and the code last month, but I stopped before committing because I wanted to make a major overhauling of the sorting and filtering stuff – namely, the removal of the sorting and filtering functions from the RecentManager class and the implementation of custom sorting inside the RecentChooser class.

At first, I designed the RecentManager object as the only proxy for every operation on the list of recently used resources; then I designed the RecentChooser interface, in order to create a uniform API to display and access the data provided by the RecentManager. It all worked without much pain: you would instantiate a RecentChooser implementation and it would create its own manager. This, though, led to an unclean separation between model and viewer in an otherwise MVC approach. I went back to the design table, and severed each direct usage of the RecentManager API that would affect the list displayed by the RecentChooser from within the various implementations. This approach allowed the usage of the same RecentManager instance inside N RecentChooser implementations – allowing, also, to have a single, session-based, RecentManager instance shared between various processes (not coded, until we can integrate all the stuff inside GTK). The only downside in this operation was due to code replication between the RecentChooser and the RecentManager; thus, like I already did move the filtering stuff out inside the RecentFilter object, I moved the sorting stuff inside the RecentChooser API (and its implementations) and out of the RecentManager – which now just manages the list, and it’s used just to add, look up and remove resources from the list it holds.

More informations on the wiki: here and here.


I also did some work on the LinkButton, the widget that should supercede GnomeHref from libgnomeui. Attached to bug #314808 there’s the current implementation.

More informations on the wiki: here.

Release Craziness

Tonight it was release time – when GNOME tarballs were due in order to allow 48 hours of smoke testing before the actual release, on January 18th.

I did the gnome-utils release, and decided to hang out a bit on #gnome-hackers – and I would have better had not to, since everything happened tonight.

FIrst comes Guilherme de S. Pastore: the newly-appointed gnome-terminal mantainer couldn’t make this release on time, and asked for someone to ship the code inside HEAD; since I love gnome-terminal (usually, I have a dozen terminals laying around on my dozen-workspace layout), how could I not help, after glancing at the bunch of bug fixes Guilherme did in the last two weeks? Also, he is on the Account Team and enabled my SSH account as fast as he could in the occasion of the last release day, so I had a huge debt of gratitude with him.

After the usual ./ && make && make distcheck cycle and update, I made the release, and hung around a bit more on the IRC channel.

A mere two hours before the end of the timeline (23:59 UTC), three patches still had to be applied to libgnome, libbonoboui and libgnomeui respectively, and then make a release of those three libraries. In a moment of slight insanity, I began working on it. The madness began.

Each patch applied cleanly to its library; I began making a libgnome release, but noticed that the patch broke libbonobo – upon which libgnomeui depends. I already did a commit to the CVS, so I had to track the origin of the breakage. It was an included header (popt.h) that was conditionally included using a pre-processor macro, but the data structures defined in there were still used and not conditionally compiled out using the same check. In order not to break everything, I had to roll out a new version of libgnome – with the header file unconditionally included. Minutes flew while make distcheck run. Finally, the 2.13.7 release of libgnome was ready. I had to install it on my system in order to make libbonoboui compile: with a mere hour to go, I still had to roll a release for libbonoboui and a release for libgnomeui.

Libbonoboui compiled fine – my fix worked fine. While I was uploading the libbonoboui’s tarball for release 2.13.1, make distcheck run inside libgnomeui. Twentyfive minutes to the deadline.

Finally, libgnomeui finished its check and created the tarball of the 2.13.2 release. I did the upload less than fifteen minutes before the deadline was due.

I’ve never had this much fun: it was a run against time, and against my CPU. Also, I gained a certain degree of automatism when dealing with the release process of a GNOME package. But, seriously: never, never again.

New release of gnome-utils

I’ve just rolled the 2.13.5 release of gnome-utils, code-named Optimized for Size.

This release sports a ton of fixes for Dictionary, which now can remember its size and state across sessions; the usage (in the Search Tool and in Dictionary) of the new, spiffy, faster and lighter GSlice slab allocator from GLib HEAD branch, which means that gnome-utils now forcefully depends on at least the 2.9.1 version of GLib; also, the Dictionary got two new localized dictionary sources, one for French and one for Spanish. I hope to add more of those sources, since it’s really quite easy and having localized dictionaries would make the Dictionary utility even more useful.

The full announcement has been posted on the gnome-utils mailing list, and it’s available here.

Be sure to grab it, test it and bug it.


I’ve began working on a new build environment for Glib, Glib::Builder.

Glib should use it, and provide it for Gtk2, Gnome2 and the other Perl bindings; well, hopefully, and when it’s finished, that is. It should also supercede not only ExtUtils::Depend but also Glib::MakeHelper and a bunch of the code we are currently using inside our Makefile.PL files. Also, it should be easier for us to port a single module to Module::Build, if we ever decide to ditch ExtUtils::MakeMaker.

How does it work?

Simply by using the right tool for the job – that is Perl and pkg-config. Each Glib-based extension will provide a pkg-config file, and inside it will export some variables useful to retrieve all the stuff that currently is exported by ExtUtils::Depend; using pkg-config we can make all these data available to every project out there that can’t rely on ExtUtils::Depend – like the programs exporting an embedded Perl interpreter (gedit, gaim, xchat, etc).

How should it look like?

This is how the Makefile.PL for a Perl module named Foo::Bar, and binding libfoo-bar would look like using Glib::Builder:

  use Glib::Builder;

  # optional code generation using Glib::CodeGen goes here

  my $build = Glib::Builder->new(
      MODULE_NAME => 'Foo::Bar',
      VERSION_FROM =>,
      PKG_REQUIRES => {
        'bar-2.0' => '2.0.0',       # C library we depend on
        'glib-perl-2.0' => '1.100', # Perl bindings for Glib
        'gtk-perl-2.0' => '1.100',  # Perl bindings for GTK
        'foo-perl-1.0' => '0.800',  # Perl bindings for Foo
      XS_FILES => @xs_files,
      PM_FILES => %pm_files,
      TYPEMAPS => qw(foo-bar.typemap),
      PKG_CONFIG_FILES => qw(,
      DOCTYPES => 'foo-bar.doctypes',
      COPYRIGHT_FROM => 'foo-bar-copyright.pod',
      ENABLE_API_DOC => 1,

  $build->create_build_files if $build;

As you can see, every dependency check is done using pkg-config, which resolves for us all the stuff needed for creating the dependency chain. Glib::Build checks if the pkg-config file exports a specific variable, named perlincludedir, which should be exported by Perl wrappers for Glib-based libraries; the location inside this variable should hold all the typemaps, doctypes and header files needed for inheritance. Another variable, named perllibdir will include the location of the shared objects needed for compiling. The Foo::Bar module would also allow other modules to access its exported data by providing a pkg-config template file, which will create a pkg-config file with all the locations automagically resolved.

This will allow the creation of modules embedded into other Glib-based projects, just by using pkg-config and some auto-foo magic; Glib::Builder could even supply some m4 macros for it, or some Perl script to be used inside or files.

All neat and stuff, but where’s the code?

Still living in my source tree. I plan to hack on it this month, but I’ve also got this semester’s finals, and some other stuff going, so I can’t really promise a release date. I really want this to be done, though. Also, since Glib, Gtk2 and the other gtk2-perl modules require special code, I’ll have to add functions for it, in order to keep their Makefile.PL as similar as possible to the template Makefile.PL: those are not (so) special cases of Perl wrappers, so I don’t want them to be treated as such.

There And Back Again

Again at home, after a week in Berlin.

The city is wonderful – now I understand why Marta loves it that much: the place is gorgeous, the people is warm and they really make you feel at home. Me and Marta were both a bit sad to leave – but we plan to return there as soon as possible, maybe even in summer, even though with the GUADEC 2006 moved at the end of June we’d already have our summer holidays covered. Time will tell.

We’ve done a ton of photos – but the last day’s worth of them (mostly about and from the dome on top of the Reichstag/Bundestag) were eaten by F-Spot; it was an older version of it, and I did the stupidest thing by deleting them from my card too, but F-Spot shouldn’t lie about having done the import and then really having finished just the thumbnailing.

While in Berlin we’ve met for a couple of hours Torsten Schoenfeld, another gtk2-perl hacker – well, he is the gtk2-perl Release Master and the Test Suite God, other than being more than Just Another Perl Hacker; he is a real pleasure to talk with and a great guy. If you ever come to Italy, you’re up for a beer, or more than one. ;-)

Now that the winter holidays are really over, let’s get back to work.

The gnome-utils release went fine (even though there’s a typo in the NEWS file I’ve submitted – dang!), and a bunch of bugs have been filed in Bugzilla. Keep them flowing, so I can know what doesn’t work. I’m off to add the window-size-saved-across-session feature that was added to the search tool, and to make the icon in the applet become a toggle button, instead of a plain icon.

Another project I’m working on is the build environment for the Glib Perl module and Glib-based Perl extensions; I began looking at Module::Build while in Berlin, but in the end, I came up with another solution – which will be easier to port to Module::Build later on, when that module enters the standard Perl base distribution. Anyway, I’ll talk about this issue later in a (lengthy) post, so stay tuned.

There are a bunch of fixes due for the libegg/recentchooser code, the main one being the sorting functions duplicated from the RecentManager object into the RecentChooser object; in the end, I’d like to remove all the sorting/filtering stuff from the RecentManager, and let all the UI built upon the RecentChooser interface provide their own sorting/filtering stuff. This would make the RecentManager object a thin layer upon the BookmarkFile object, and would really make things easier to be included into the GTK library. In the end, all the sorting a filtering is something that has to do with the display of the data that the RecentManager holds, so they do not belong into the manager itself. Other than this fix, I’ll begin working on a patch for the BookmarkFile object in order for it to land inside Glib, and a patch for the FileSystem object to use it for its bookmarks.