Nautilus Extensions are Easy

I really like the Baobab disk usage analyser that is included in gnome-utils, but more often than not I’m in the middle of using Nautilus to sort through my files and folders when I want to analyse the disk usage. So I thought, wouldn’t it be convenient if I could just get to Baobab straight from a context menu in Nautilus? It turns out writing Nautilus extensions was much easier than I thought, especially when you start by copying an existing one. Within a few minutes, I had my Analyse Disk Usage context menu item. I’ve posted it in bugzilla as a patch to gnome-utils, in case anyone else thinks it would be useful. If it was integrated into GNOME, it should probably be disabled by default and an option in Baobab would enable it.

And in case I haven’t explained it very well, he’s a screenshot:


Contacts 0.9 Released

Plenty of bugs fixed in this version. I am hoping to use this as the release candidate for version 1.0, so please send in any updated translations either to me (thomas at or attach them straight to bugzilla. Also, I haven’t fixed many Maemo issues because we don’t really support the Maemo version (Maemo already has an address book anyway…). However, I’m more than willing to apply patches if people are able to supply them.

I’d like to add a special thanks to Adrien Bustany and Gilles Dartiguelongue for their patches that I’ve included in this release. If anyone else has any (small) feature of bug fix they would like to see done before 1.0, now is the time to start working on your patches!

Overview of Changes in 0.9 (since 0.8)

Bugs fixed:

  • 139: Contacts does not exit cleanly, leaves socket behind
  • 169: horrificially non-obvious choices of field names
  • 224: Search chokes on non-ascii chars
  • 275: tab key behavior inconsistent
  • 305: Available labels for email are insane
  • 306: Better location labels for us stupid Americans
  • 308: No way to view “unfiled” contacts
  • 309: Groups dropdown in main window not alpha-sorted
  • 310: Contacts does not create “file under” field, not usable in Evolution
  • 318: Do not show fields that are blank
  • 338: Possible to add duplicate groups to a contact
  • 339: Keyboard shortcut conflicts
  • 341: Unexpected triple-click behavior in Name/Groups display
  • 368: Should import concatenated vcards
  • 489: Missing field definitions in Contacts.
  • 492: Only installing 26×26 icons when building for Maemo platforms.
  • 659: New contacts do not have a N: field – my mobile reject them
  • 774: Fails to build from source under Ubuntu Hardy
  • 808: All vcards for companies are displayed as ‘Unnamed’
  • 885, 42: Attributes not sorted in view mode
  • 888: Contacts segfaults when provided with incomplete options on command line
  • 890: Typos in source code
  • 893: Remove recursive function
  • 896: Simple DBus interface



Reporting Bugs

Please report any bugs using the bugzilla bug tracker at:


Screenshots and more information available at:

gnome-appearance-properties profiling update

It seems Federico’s hunch was correct and the majority of time in show_all is spent analysing icon themes and loading the images.

I noticed that /usr/share/icons/gnome/icon-theme.cache was missing, so I ran gtk-update-icon-cache to generate the file and the result was quite significant.



The total time to execute show_all went from 0.85 to 0.24 seconds, which is a reduction of about 72% and saves over half a second of start up time. I am now left wondering why the icon-theme.cache was not present and whether I have a more responsive desktop as a result of creating the cache. Perhaps we should be running gtk-update-icon-theme-cache as a post-install operation for gnome-icon-theme?

Profiling gnome-appearance-properties start up time

I’m sure I’m not the only person to have noticed that gnome-appearance-properties takes quite a while to start up. On my system (a 2GHz Athlon XP), it takes an incredible three seconds to start this little preferences application.

So, I decided to do something about it. I used the Federico Technique to insert some debug messages to create a graph of the start up process.

My first attempt produced this graph:


From this, it is clear there are a few bottle necks during start up, with desktop_init being the biggest. desktop_init is the function that initialises the desktop backgrounds tab of the capplet. So, to investigate quite why this was taking such a long time to complete, I added some more log points.


From this, it was quite clear that the time was being consumed entirely by creating the file chooser widget, used when users want to add new backgrounds to their list. So I added yet more log messages to determine if there was one or more function calls responsible:


It turns out that the gtk_file_chooser_dialog_new_with_backend() function is taking just over 1.5 seconds to complete, or approximately half the start up time for the entire application. Thankfully, the widget is not required until the user actually clicks the “Add Wallpaper” button, so by delaying the creation of the widget, we can reduce start up time by half.


There are clearly some more places to investigate and I’ve started looking into the app data init and themes_init sections.


The next biggest places to investigate appear to be the gnome_theme_init, thumbnail generation and the style_init. However, the biggest block by far appears to be show_all, which is now taking up almost half the startup time.

Does anyone know have any ideas about why gtk_file_chooser_dialog_new_with_backend() took so long to finish, and indeed why the show_all function take so long to complete? Would it be practical to only call gtk_widget_show when the tab becomes active? I suppose there is only one way to find out…