context switch

End

Happy new year!!!

Source

Feeling a little better, today: temperature steadily under 37°C, little to no headaches.

I’ve hacked the last bits of the Add Source dialog of Dictionary, and committed away a bunch of other fixes, including one for a crasher spotted by Paolo Borelli, a bunch of UI fixes by Dennis Cranston and corrections for my bad english by Clytie Siddall. Thanks to all of them: with their help, the next release of Dictionary will suck a lot less.

The Add Source dialog makes me feel a little proud:

Here you can see the dialog when you click the “Add” button; you can set the description of the source and its transport. Choosing a transport will automagically show the preferences bound to that transport:

Obviously, since libgdict supports only the Dictionary Protocol transport, you have only one choice, but expect other transports to be available from the next release of GNOME. The “Advanced Settings” pane will expose the Database and Strategy settings:

Those two combo boxes should automagically query the dictionary source using the GdictContext bound to the transport the user has chosen; unfortunately, they don’t - yet. I hope to get around this issue before the code freeze, but I really don’t know if I’m going to make it in time.

If you want to have a look at how it all works, I’ve prepared a little screencast (courtesy of Istanbul).

[hacking]
[gnome]
[gnome+dictionary]

Health

As usual, I’ve got a flu at the end of the year.

This really sucks, because due to the slight fever and the cold, I had to cut back hacking time; the re-write of the source dialog in Dictionary has begun but I don’t know if I can finish it up before the next release.

Other things I‘m was working on: new features for the Gnome2::GConf module; fleshing out the GTK2-Perl tutorial; writing the Dictionary manual; updates to the RecentManager/RecentChooser code.

Inkscape

On a IRC conversation, I was told that the Dictionary icon sucked. Thus, after having a look at the Tango Project and their beatiful icons, I fired up Inkscape and worked on another version of the icon:

It still sucks, but now it sucks in 3D!

I’ll file a bug report to remove the old “gdict” icon from the theme, and ask the GNOME artists to do a new version, with more than one size.

Gnome2::GConf 1.021

The “An Address Indicates Where It Is” release.

New release of the Perl bindings for GConf, in time for the incoming GNOME 2.13.4 release.

This version sports a bindings for the Gnome2::GConf::Engine::get_for_addresses method of the Gnome2::GConf::Engine class; this method allows the creation of a Gnome2::GConf::Engine for a list of addresses. Many thanks to Laurent Simonneau for letting me know that the method was missing.

The get_for_addresses method was added in the GConf 2.7 cycle, and if you compile Gnome2::GConf against a newer GConf version, you’ll get it. You should be extra careful with it, and check for its usage, since I can’t test it (as well as all the Engine-related methods) using the automated testing platform we use for all the Perl bindings. But, hey: that’s what beta releases are for, aren’t they?

You can find the tarball of this release on the gtk2-perl project page at SourceForge, and hopefully you’ll find it on CPAN too.

[hacking]
[perl]
[gtk2+perl]
[gconf]

Maybe this Christmas

Only a few minutes into Christmas, and a few hours before the traditional lunch and dinner of this day.

In the last four days I feel like I’ve already eaten more than I usually eat in a month. On Tuesday, me and Marta celebrated her birthday with some friends; on the 22nd - the real date of her birthday - just the two of us went to a japanese restaurant here in Milan, to celebrate by ourselves; on the 23rd we went with my family to a restaurant to celebrate both Marta’s and my father’s birthday. Today, we went to lunch with Marta’s parents. Tomorrow (well, today) we are going to have lunch with Marta’s relatives and dinner with my relatives.

This is our first Christmas together (last year, I had to go around all night with the band, playing christmas carrols from 10pm to 6am), and we are celebrating in our own way: she is finishing the translation of her under-grad thesis in order to send it around and get a PhD abroad and I’m finally committing the last features of the GNOME Dictionary. We’s so two geeks.

Now, Dictionary allows the creation (and the removal) of dictionary sources using a nifty UI (it already worked by dropping the dictionary source .desktop file inside $HOME/.gnome2/gnome-dictionary, but with a UI this becomes a little easier for everyone). The dialog still has rough edges, and I think that the code stands out as a little too messy - especially against the overall cleanliness that I tried to keep in the project. I’ll remove it as soon as I can, and will use a proper class for that dialog; for the time being, I tried on making the magic happen as fast as I could, since we are approaching release time.

The next gnome-utils release is due at January, 2nd; I’ll try and get everything in shape before that day, in order to let people use the new Dictionary application and begin filing bugs. I won’t be around when the next GNOME unstable release will happen; instead, I’ll be in Berlin since January, 3rd till January, 10th, for a week of well due holidays.

[hacking]
[geek+xmas]
[gnome]
[gnome+dictionary]

Fun with Cairo-perl

Just a little fun with the Cairo Perl bindings. The code is courtesy of the gtkmm tutorial, and can be found here.

Sadism, Bestiality and Necrophily

Or “Flogging a Dead Horse for Fun and Profit”

Spatial Nautilus. Again.

Both Ubuntu Dapper and Novell Linux Desktop will ship with browser mode by default for Nautilus - now that browser mode got much love, enough to be usable.

While both Ubuntu and Novell, as GNOME packagers, are entitled to change as much as they wish to the applications’ GConf schemas, I think that upstream GNOME should continue to ship with the spatial Nautilus; changing now would confuse new users just as much as did when we shipped with spatial Nautilus - with the aggravation of swinging back and forth.

GNOME has made a decision of treating each “first class object” as a window itself: documents, folders, people. With the approaching of Topaz this will become even more true. The browser paradigm breaks this.

So, it’s fine if Ubuntu, Novell, Red Hat, and ${WHATEVER_DISTRO} ships with its own version of GNOME - they already rebrand it; but upstream GNOME is another beast entirely.

Icon

I’ve just committed my development trunk of the BookmarkFile and RecentManager objects. The former now supports custom icons for every bookmark inside the file, using the icon element; the latter, finally, supports group names for every recently used item.

I’m writing a small page for documenting how to port an application from the old EggRecent code to the new RecentManager, and also how to use the new RecentChooser widgets.

On a related note, I’ve been contacted by other developers interested about the RecentManager/RecentChooser code; expect more news soon.

Evolution

If this is ever going to happen, then I expect a Unix-based Windows release within the next two years.

Spawn of hell

auto-tools: from the same people that brought you EMACS.

After two hours of struggling with that damned make distcheck, in order to smoke test the merge of the new-dictionary branch of gnome-utils, I’ve finally been greeted by:

===================================================
gnome-utils-2.13.4.tar.gz is ready for distribution
===================================================

After a bit of clean up, I’m going to commit it to HEAD.

Update 20051216@19:18 The new GNOME Dictionary is in gnome-utils HEAD; the old Dictionary is gone into the Attic. I for one welcome our new dictionary overlords.

[hacking]
[gnome]
[gnome+utils]

Dictionary Applet/11 and final

After two months, here’s to you:

The New! And Improved! Dictionary Applet.

Soon to hit gnome-utils HEAD on the repository mirrors near you!

[hacking]
[gnome]
[gnome+dictionary]

Dictionary Applet/10

The merge of the new-dictionary branch into gnome-utils HEAD is fast approaching: I’ve set the deadline to the end of the week - in time to write off the last bits of the preferences dialog:

the sources tab of the preferences dialog

Right now, you can’t add or activate a new dictionary source, unless you write the .desktop file and drop it into $HOME/.gnome2/gnome-dictionary, and then change the /apps/gnome-dictionary/source key inside GConf - but I plan to have this nailed down in the next couple of days (the UI for both display and edit has already been designed using Glade).

the printing tab of the preferences dialog

The font selection thingy for the printed output is, instead, already working.

Known regressions: the text highlighting is still missing, and I don’t know if it’s going to make it not only before the merge deadline, but also before UI freeze.

[hacking]
[gnome]
[gnome+dictionary]

Dictionary Applet/9

I’ve added printing support - after a bit of struggle with GnomePrint:

The output format is stolen^Winspired by Gedit, and the font is hardcoded as Serif, 12; I’ve already added a GConf key to the shipped schema - GConf integration, as well as preferences are still in a state of flux. Now that the printing is mostly nailed down, I’ll resume work on the UI side, by adding a status bar and the preferences dialog. Also, work on the applet will begin as soon as these issues are solved; the applet should be, in fact, very easy to code.

Note: It seems that a critical warning is issued each time a print dialog is destroyed and then recreated - like some signals handlers that aren’t correctely disconnected; I’ll have a look at it, but it seems a bug of libgnomeprint as far as I can tell. Update 20051212@02:53: it is now bug #323836 of libgnomeprintui

Also, judging from the memory consumption, I’m afraid of some leakage inside libgdict (mostly). I’ll have a run with Valgrind, and see what’s going on under the hood. Update 20051210@16:33: it seems that I was fooled by the system monitor memory usage graph, as I found two simple leaks (due to me being a sloppy coder), accountable of just 6kB lost - and just once per process, since one was inside the singleton init, and the other inside the GdictSourceLoader directory walking. Both are now fixed inside my development trunk. I’m positive that, if the trend continues, the new code might land inside HEAD the next two weeks - given that the preferences dialog and the dictionary source creation code are pretty much done, and that the applet will be easy to code. Once we reach feature freeze time (in January), I’ll devote myself in writing a good user’s manual. Some might think that the next release will be a regression, but believe me: the trade-off of a few features for code readability, maintainability and overall performance is well worth it; features will be re-implemented in no time.

[hacking]
[gnome]
[gnome+dictionary]

Maintainership/2

I’ve just committed my development trunk of Dictionary on the CVS, as usual to new-dictionary branch.

Features

• a navigation menu, with shortcuts for first/previous/next/last definitions
• a Ctrl+Shift+G shortcut for search backwards
• a “Save a Copy” menu item, used to save the content of the query to a text file;

It also features a stub for the user’s manual and some clean-ups for the build system.

What’s next?

I’m working on the printing system and the preferences dialog.

I’ve decided to remove the font preference, in order to make it the same of the desktop; I don’t want yet another font chooser. The only place where it makes sense to have another font is when printing - and for that we might just have a key in GConf.

Also, the text highlighting is going to be scaled down: since we are going to use multiple dictionary sources, over multiple languages, we really don’t know a priori some things, like how the enumerations will look like. The only text modifiers I’m going to keep will be [...] attributions (which will be rendered using italics); \...\ phonetics (which will be rendered in a styled color, default: gray); {...} links (which will be rendered in a styled color, default: blue).

[hacking]
[gnome]
[gnome+dictionary]

Maintainership

Vincent kindly asked me to join the maintainer team of gnome-utils, and I more than gladly accepted.

In order to celebrate the event, here’s the latest screenshot of my development trunk for Dictionary:

the new Dictionary

As you can see, the current state is not far from the actual, stable, Dictionary:

the old Dictionary

What’s missing:

• the text parsing
• the menu callbacks
• the preferences dialog
• the user’s manual
• print support

The feature equivalence could require a bit more time than foreseen - especially the printing part and the manual - but I plan to have everything in place befor Christmas: think of it as my gift.

I plan to commit the new-dictionary to HEAD as soon as I have finished the menu callbacks and the preferences dialog.

[gnome]
[hacking]

Documentation

In the last thirty minutes I’ve ported gnome-utils to the new, spiffy gnome-doc-utils system.

I hope that this could hit HEAD in the next few days (pending Vincent’s approval)- the sheer amount of stuff deleted and/or changed is really high. This would allow better translations of the documentation of the tools inside gnome-utils.

Leaking/2

After some six hours, a chinese dinner, two large glasses of earl grey tea, and a coffee, I’m finally able to declare that, according to Valgrind, both the libegg/recent-files and libegg/recentchooser code are leak-free.

Okay, take this with a grain of salt, as I’m not that good with Valgrind, and some of the logic of my widgets might lead to leaks; as far as my mallocs are concerned, my code is leak-free

[hacking]
[memory+leaks]
[gnome]

Leaking

Yesterday, while I was at university waiting for a seminar about network security, I was on #gnome-it, and pbor asked me to look at a leak in EggRecentModel. I began wading through the code, but I didn’t found the leakage in time before having to leave.

In the evening, after I got back home, Marta went to her church choir practice, and I looked at recent-files/egg-recent-model.c using Valgrind (and practicing with it, since I’m not that good with this tool); using the function chain reported by valgrind, I noticed that the leak was inside the logic used by egg_recent_model_filter. This function scans the list of EggRecentItem objects built from the on-disk storage and filter out using the three pre-defined filter functions (while my RecentManager object supports only custom filtering function, and the RecentChooser implementations might filter the recently used resources list using a more complex RecentFilter object). The problem is that it used the infamous GList scan using while():

  while (list) {
    SomeData *obj = l->data;

    do something with the object

    list = list->next;
  }

This code is perfectly valid: it walks the list by exhausting it; that is: the list pointer reaches the end of the list once it reaches the end of the while. Valid code does not mean right code, though. Suppose you want to move the items of a list inside another list. By using the code above, you would have:

  GList *newlist;

  /* init the target list */
  newlist = NULL;
  while (list) {
    SomeData *obj = l->data;

    if (some_condition)
      newlist = g_list_append (newlist, obj);

    list = list->next;
  }

This code is also perfectly valid for filtering a list. Suppose, now, that you want to destroy the original list and return the filtered copy; you’ll have to free the GList using g_list_free() at the end of the while cycle:

  GList *newlist;

  /* init the target list */
  newlist = NULL;
  while (list) {
    SomeData *obj = l->data;

    if (some_condition)
      newlist = g_list_append (newlist, obj);

    list = list->next;
  }

  g_list_free (list);

  return newlist;

But we said above that the list is walked by exhausting it; hence, the list pointer is now NULL (the exit condition checked by the while cycle). Thus you are leaking the old list; to avoid this leakage, you must walk the list keeping a pointer to the list start. In order to do so, the right thing to do is to use an iterator pointer, and a for() cycle to keep the cycle compact and avoid messing up with the list = list->next assignments on every cycle break condition:

  GList *newlist, *l;

  for (l = list, newlist = NULL; l; l = l->next) {
    SomeData *obj = l->data;

    if (some_condition)
      newlist = g_list_append (newlist, obj);
  }

  g_list_free (list);
  return newlist;

This code does not leak the old list, but it leaks the data that was not moved to the new list; if the function to free the data is called some_list_free, the code above becomes:

  GList *newlist, *l;

  for (l = list, newlist = NULL; l; l = l->next) {
    SomeData *obj = l->data;

    if (some_condition)
      newlist = g_list_append (newlist, obj);
    else
      some_data_free (obj);
  }

  g_list_free (list);
  return newlist;

As a performance sidenote: if the list is long, you might consider using g_list_prepend, since it’s a constant time operation, while g_list_append walks the list; just remember to return the reversed new list:

  GList *newlist, *l;

  for (l = list, newlist = NULL; l; l = l->next) {
    SomeData *obj = l->data;

    if (some_condition)
      newlist = g_list_prepend (newlist, obj);
    else
      some_data_free (obj);
  }

  g_list_free (list);
  return g_list_reverse (newlist);

I had noticed the leak around 10:30pm and began fixing it, but I had to pick up Marta and both returned home at 11:30pm, when we went straight to bed and fell asleep almost immediately. This morning, I found bug #323002 awaiting, with a fix for the first part of the leak (thanks to Paolo). Now, libegg/recent-files HEAD has the leak fully plugged. Subsequent runs of valgrind showed no mor leaks related to the recent-files.

Now, I’m going to check my libegg/recentchooser and my libegg/bookmarkfile code for leaks.

[hacking]
[coding+style]
[memory+leaks]