Author: thos

LinuxLiveExpo was last Thursday, Friday and Saturday. This year it was held in combination with CreativePro and MacLive expos. Aidan arranged for GNOME to have a stand in the .org village and Michael and I helped out manning it. Unfortunately the GNOME event box went missing so it didn’t arrive for us to use (it has since turned up in France!). It seemed a lot quieter and a lot smaller than previous expos, but we still had fun on the Saturday evening when we went to a local pub with the KDE and OpenStreetmap contingent. It’ll be interesting to see if the Expo format survives much longer, but it still seems to be a good place to introduce people and small businesses to FOSS and GNOME.

It’s that time of year for the Linux Expo again (well actually it didn’t happen last year…). The dates are 23rd-25th October and this year it’s going under the guise of “LinuxLive Expo“. Interestingly, it is being co-located with CreativePro Expo and MacLive Expos, so there will certainly be lots of interesting things to see in addition to the normal .org village and other Linux vendors.

Aidan is organising the GNOME outing for this year and has set up a wiki page to co-ordinate manning the stall. If you can spare a few hours on any one of the days, please put your name down. We may even organise a pub meeting on one of the evenings.

We chose the new backgrounds for 2.24 at GUADEC, but it wasn’t until a few weeks ago we got round to integrating them into the gnome-backgrounds module. Have a look on the theming blog for a preview of the new images.

(Yes! I get first post to the new GNOME theming blog!)

Back from Guadec, which was great. Few interesting points:

• I am not actually Linux Hater, despite my colleagues attempts to spread vicious rumours to the contrary.
• Pleased with GTK+ 3 decisions, obviously lots of thought and planning gone into this. Glad to see long term goals being put in place.
• Had some good meetings/BOFs about artwork and GTK+ theming.
• Chose the wallpapers from the wallpaper contest, despite Kalle falling asleep during the process and refusing to wake up
• Had fun playing a lovely red saxaphone at the opening party
• Got some good hacking time in, and resurrected my Pixbuf theme editor, now renamed Monet (code available soon)
• Lots of interesting talks on user experience and user interface design, especially the keynotes and Andy Fitzsimon’s talk. I am now wishing I had taken some proper notes, but I hope the slides/videos will be online soon.

My new tasks are to release some version of Monet fairly soon, and to start work on a GTK+ theme engine to implement some of the css style GTK+ theming thoughts I had a while back.

Thanks to everyone that helped organise this years Guadec. It was a great event and of course great to catch up with old friends and meet new ones.

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:

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.

Before:

After:

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?

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…