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.
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. ;-)
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
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.
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:
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.