At the end of this week I’ll be in Copenhagen for the Nordic Perl Workshop. I’ll give two talks about GNOME and Perl: the first one is about binding GObject-based libraries in Perl and using the Perl bindings in order to write GObject-based native Perl modules (and get all the GObject features); the second one is a GTK+ tutorial-slash-faq-slash-best practises for Perl developers. I’ll be around in the city from the 27th till the afternoon of the 29th (I have to get back early, unfortunately).
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!
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
:
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:
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.
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:
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:
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.
John Saw That Number
Thanks to Ross and his mad python-fu skillz, now we have a working Python binding for gtkunique – for the brave souls which may want to use it.
The repositories locations have been changed, after the servers update at OpenedHand, so here’s where the fun is:
trunk: bzr branch http://folks.o-hand.com/~ebassi/bzr/gtkunique python: bzr branch http://folks.o-hand.com/~ebassi/bzr/pygtkunique perl: bzr branch http://folks.o-hand.com/~ebassi/bzr/gtkunique-perl
Testing is greatly appreciated.
gtkunique future: GtkUnique is API frozen, and feature complete as far as I’m concerned (bug fixing and eventual feature requests notwithstanding). I’ve opened a bug for integration into GTK+: #378260. You can watch it and give your opinion there.