Get Innocous!

Lately, people have been trying Clutter, and reported bugs and misbehaviours. When asked what revision they were using, it turned out that they did a checkout from Clutter-core trunk. I made this point on the mailing list already, but I’ll just blog it so that it doesn’t get lost (until we have set up some web archives for the list): Clutter trunk is meant to break basically with each commit – so you should checkout trunk only if you want to help developing Clutter. If you want to use Clutter from SVN, check out the clutter-0-2 branch. Each stable release of Clutter (0.2, the next 0.4, etc) is guaranteed to be ABI and API compatible within the same minor release; until we reach 1.0, we’ll also keep providing support for parallel installations, so that you can target a specific minor revision without breaking.

So, if you want to try out Clutter, use the stable branch – and remember to file bugs against that.

Falling Away With You

A couple of weeks ago I decided to give git a try, after this old post written by nud about using git-svn to create a bridge between a project stored under a SVN repository and a git repository.

I’ve choosen Clutter mostly for these reasons:

  1. I wanted to create a distributed branch of Clutter in order to avoid huge commits after offline periods
  2. have a semi-private crack-powered tree for experimenting with some ideas without having to taint the SVN repository
  3. the number of revisions in the main repository is low (< 1000) so I could import the whole history in a reasonable amount of time

I fired in my terminal the git-svn commands and less than ten minutes later I had a fully working git repository for Clutter, complete with history. What I liked from the very beginning were the lightweight branches git employs; you can have multiple branches inside the same work directory and you can switch between them with a single command. Actually, I found that having a single branch for each one of the changes and then merging them back into the main work branch is an incredibly natural way of dealing with the development of a project; it’s like having a locally distributed approach – which git makes it easier to adopt than, say, bazaar; the git-web interface is also really sweet, and much more useful than viewcvs alone (and, in many cases, of the viewcvs+bonsai coupling); finally, the speed factor is huge: each command, except for the cloning of a repository (which is something you end up doing just once anyway) is almost immediate.

Time For Lovin’

You can see I’m listening to the Beastie Boys, right now

In the last three days I’ve finally managed to resolve as fixed these GTK+ bugs:

  • Bug 347375 – Not possible to set startup notification ID on a GtkWindow
  • Bug 418219 – GtkRecentChooser should apply filter before sorting and clamping the list
  • Bug 418634 – gtk_recent_chooser_menu_set_show_numbers docs
  • Bug 418673 – gtk_recent_manager_add_item
  • Bug 338843 – add recent files support inside the ui manager

Bug #347375 contained a patch Vytautas Liuolia wrote last year, as part of his guniqueapp Summer of Code project.

Bugs #418219, #418634 and #418673 have also been backported to the stable branch, as they fixed documentation or simply bad behaviours in the code.

Bug #338843 finally closes the long standing bug about the integration between the recent files and GtkUIManager; you can now add a GtkRecentAction to your actions group and let it do the right thing.

Many thanks go to Vytautas Liuolia, Matthias Clasen, Paolo Borelli and Morten Welinder.

Shazam!

GNOME 2.18 is out! Go and check it out!

gnome-utils-2-18-thumb.jpg

Obviously, the release of GNOME 2.18 means that we can now start working on 2.20 – after a well deserved beer. ;-)

Of Angels And Angles

GtkApplication class: I’ve updated the application class page on the wiki. Now, it has an updated layout of the API (which is what I’m currently working on) and the design requirements it should fulfil. While writing it I had some sort of epiphany about the whole library consolidation effort and its perception among the platform developers. Project Ridley as it stands is a double-edged sword: on one hand we’d like to have more functionalities moved from external libraries to GLib and GTK+; on the other hand, the size of the platform libraries maintainer teams is not growing at the same rate. If we are to move widgets, features and whatnot to GTK+ we must be sure not only that someone is actively working on them after inclusion, but also that someone is willing to work on the rest of the codebase, in order to review the patches leading to the inclusion of new functionalities. So, waiting for Project Ridley to come to the rescue is not going to cut it anymore: if you are proposing to move some functionality from a library to GLib or GTK+ be prepared to work on the whole code and not only on your pet feature.

GtkUnique: since a “single instance application class” doesn’t really make any sense without an “application class” to make it inherit from, I’m punting the GtkUnique inclusion in GTK+ until the application class lands in first – and that makes it part of the post-2.12 masterplan; hence, I’m going to remove the gtk namespace from gtkunique and releasing it as a standalone library for the time being. I’ll commit the namespace switch before this weekend: it’ll switch from GtkUnique to Unique; everything else will stay the same. Remember to check it out from GNOME SVN server:

  svn co http://svn.gnome.org/svn/gtkunique/trunk

GConfig: as I mentioned in the last blog post, I’m working on the next iteration of GConf. Aside from ongoing design and API churning, I’ve also submitted a talk proposal for the next GUADEC about how to tackle the whole ‘GConf issue’. GConf is part of the core GNOME platform, and it has been so since 2000; it’s almost seven years old, and now it begins to show its age. Since 2001, Havoc has been asking the community to implement the same set of (five) features; no one has answered his call yet. Maybe the community is to be blamed for this; maybe we need to rethink part of the GConf design to allow someone other than ‘the usual suspects’ to fix GConf shortcomings and add new features. For instance: the backend API is a really nasty piece of code and it’s not easy to drop a new backend into an existing GConf installation; probably, that’s also why, after all these years, we still have only the XML and had to wait a long time for the evo-ldap backends. I’m going to put a page on the wiki with what kind of API I’m thinking about.

talks: aside from the GConf talk, I’ve also proposed a talk/tutorial about the Perl bindings for GTK+. I’ll also do two talks about Perl, GObject and GTK+ at this year’s Nordic Perl Workshop which will be held at the end of April in Copenhagen.

Live Wire

Back from FOSDEM 2007, after a little detour in Helsinki.

I’ve opened a bug for the places support in GtkFileChooser: #413076. Attached to it you’ll find a patch; it should be taken with a grain of salt: it’s still a work in progress, but implements the main features and shows how the new API should work. In short, if your application need to use some predefined, user visible folder and you want to provide a link inside the file chooser, you need to create your bookmark file, drop it somewhere and call:

gtk_file_chooser_add_shortcuts_from_file (file_chooser
                                          "/path/to/bookmarks.xbel",
                                          NULL);

We’d need an intltool able to recognise the title (and eventually description) markup elements of the bookmark files and merge them into the translation pool, so that you can have the places already localised (the machinery is already in place in the patch). I’ll keep working on it, and finish up the implementation of the automagic places that applications can install in a common place and have it appear in every file chooser, based on the group or application name used in the bookmark.

I’m also working again on the Application class (the wiki page is really out of date with the current iteration I have been workin on – I’ll update it as soon as possible); now that the session management code has landed in libegg I will add hooks into the application class to have it do The Right Thing®. Other than an application class, GTK+ really needs a desktop abstraction – a simple API to know whether we are connected to a network, or to control the screensaver, or to launch the default browser/mailer/editor/whatever. For that to work properly we should really have a working configuration system like GConf moved below GTK+. I did some prototype API for a configuration engine, mostly stealing^Wtaking inspiration from alexl work on GVFS (which already has a nice and clean API); will probably have something usable soon.

Like Eating Glass

Desktop-devel-list (d-d-l) is an interesting place. You follow discussions that usually tend to fork off, moving through tangential arguments; but, in the end, some stuff keeps turning up. Lately, for instance, every thread seems to end up on discussing about Tracker.

Let’s take the discussion about having a GNOME “media center version”; you could think that such a discussion will end up laying out some ideas about a media center. Wrong: we ended up discussing about special folders – an argument that has already been discussed to the death. Obviously, if you read d-d-l all day you can’t really expect having time to actually work on the features (or the crack) proposed on the list. So, for a change, I decided to do stuff after saying what could be done. I decided to take an idea that has been floating around for ages and implement it.

This is a simple FileChooserDialog, but the places list have been generated using a bookmark file (read using GBookmarkFile) in $HOME/.local/share/places/gtk-bookmarks.xbel instead of $HOME/.gtk-bookmarks:

FileChooser using bookmark file
It’s completely identical to the FileChooser in trunk, really, but the places on the left are parsed using this.

The code, obviously, merges the places saved using the old format.

This, instead, is a trivial Perl application that can read all the places; it can also edit them, add new places and remove old ones:

GTK+ shortcuts editor

The fun part about switching the file chooser to the bookmark files is that it’s public API, so everyone can read, change and write these locations. We can add new locations to an application like we add Glade files, and let the file chooser populate itself by loading a file; so, instead of using:

  gtk_file_chooser_add_shortcut_folder (file_chooser, some_location);

we could use:

  gtk_file_chooser_add_shortcuts (file_chooser, PKGDATADIR "/shortcuts.xbel");

But wait, the keen reader familiar with the issue will interrupt, the whole point of this mess is localising the name the user sees in the interface. Indeed, that’s why the bookmarks have a title and a description; through intltool we can extract those two and put them into the po file for the translators to work on – exactly like we do for the Glade files. Before displaying the bookmark will pass the string through gettext, which will return the localised alias using the application’s domain – or we could add domain argument to the gtk_file_chooser_add_shortcuts() function above.

The file chooser can also load shortcuts automatically, using the application name to filter out what’s interesting.

Is this the most correct solution for this problem? I don’t really know, even though using bookmarks and applications make more sense than using dot-desktop files and MIME types (come on? MIME types? Like I should bind a directory to specific types of content and not to the applications that are most likely to use them – and what are “MIME types” anyway?). At least, however, this is a start and there’s some code to comment on.

The patches are roughly done, but the real treat would be to split the places section of the file chooser widget into its own widget and let other applications, like nautilus, use it directly without having to cut and past tons of code out of GTK+.

Come and See

Decemberists: Yesterday evening, The Decemberists were in London, and made a wonderful concert at Shepherd Bush. I’ve fallen in love with the band after vieweing the video of their song Sixteen Military Wives and I started getting my hands on their whole discography (right now, only the singles are missing). They played mostly songs from their new album, The Crane Wife, which is really as good as it can get (so go out and buy it now).

gnome-utils: It seems that my plea for someone to work on GFloppy has been useful; right now, Paul Betts and Riccardo Setti are working on a replacement using HAL and libparted, and are also getting the ball rolling for adding formatting support directly in HAL. Guys, you rock!

GTK+: I’ve been working on fixing some bugs of the GtkRecentChooserMenu widget; specifically, bug #377164 and bug #405696. While I was at it, I finally closed the FIXME I left in code, for supporting both appending and prepending custom menu items in the recent files menu, and finally added a test case for the widget, so I can track regressions.

Recent files menu
Obligatory screenshot of the test application

FOSDEM ’07: Like last year, at the end of February I’ll be in Bruxelles, attending FOSDEM.

Small Stakes

Tonight I released version 2.17.90 of the GNOME Utilities package.

It’s not just another release: it marks the end of the work on the interactive dialog of the screenshot utility:

GNOME Screenshot Interactive

Now every command line switch is replicated on the interactive dialog that comes up when you launch the screenshot utility either from the menu or from the command line using the --interactive switch; each setting is taken into account, so calling gnome-screenshot --interactive --delay=5 --window --border-effect=border will change the UI accordingly (this very command line produced the dialog above).

This point release also marks the beginning of the work for the next development cycle; instead on working on the main trunk, I’ll open branches for the features I plan to add to the various components of the Utilities package:

  • plugin support for the System Log Viewer; this has already been written by the (great and incredibly patient) Lin Ma from Sun, but it still needs some cleaning up;
  • local sources for the Dictionary; as above, there already is a patch but needs to be cleaned up;
  • a new save dialog for the Screenshot utility;
  • add an area selector for the Screenshot, so you can pick a specific part of the desktop;

I’m also considering dropping the Dictionary applet from the Utilities, as its functionalities are pretty much covered by the plugin of the deskbar applet, and the deskbar applet is considerably more worth your panel space. The only thing that keeps me from removing the applet is that the deskbar applet is written in Python, and this might be an issue for slower machines; I could move the applet out of tree into its own package and let the distributions or the single users pick it up.

What I would really like to do in the next cycle is to revive GFloppy. At the moment, is compiled conditionally and it’s pretty much useless unless you have a floppy drive and the floppy utilities installed (it can use HAL to check for the available drives, but HAL doesn’t have the ability to programmatically format a volume); since not many computers come with a floppy drive anymore, I’d like for someone with HAL knowledge to pick GFloppy up and find a way to make it work with removable devices, like USB or flash solid state memories. Otherwise, I’ll have to consider dropping GFloppy too, as I don’t have a floppy drive anymore and can’t obviously maintain an application I can’t test.

Finally: if you have a small utility you deem useful enough to end up into the Utilities package, send me an email and propose it for inclusion.

Wonderboy

A couple of days ago, thos wrote about the branding of the GNOME System Monitor; soon after that, a bug was opened about the image – how the colour was off for every non-blue theme, and how it went against the GNOME logo branding rules – and the image was removed. I liked the branding, though; and so did Luca Cavalli – so much, actually, that he wrote a patch for having the image coloured depending on the theme and with a full GNOME logo:

Themed System Monitor Image

According to him, the patch still needs some clean ups, but I think now it would really be a great thing to have in the System Monitor for GNOME 2.18. Update@2007-01T09:44: the patch has been attached to bug #377144.