gtk+: the gtk+ team meeting on tuesday went really well — and part of the discussion was incorporated in Kris always excellent State of the union talk. the team went over and over this issue since last GUADEC and during the hackfest, and even though something at some point will probably go wrong the plan is good and allows leeway to reduce the overall effort for moving the entire platform. I think that given the circumstances this is the best plan that can be realistically implemented.

gnome: everyone will be discussing the release team plan as well. I can only say: let’s do it!

clutter: the Clutter Guts talk went really smoothly; we tried to fill Matthew shoes — and had to be in three to do it — but I think people came out of the talk with more knowledge about the deep magic and the pixie fairies dust that power Clutter and make it as awesome as it is. as I said during the talk, Clutter 0.8 is really in the final stages now, and it’s going to be released as soon as we finish testing some of the backends. people will just have to wait a little bit, but by the time everyone gets back home from GUADEC they will be able to get the tarball from the server.

• use GIO to determine the MIME type of a URI, on every platform supported
• use the file monitoring API to avoid polling the storage file
• add a GtkSettings property for clamping the recently used resources list to a 30 days limit

more stuff I’d like to add is:

• small parser changes to GBookmarkFile, to reflect changes in the spec
• bulk addition, for applications storing multiple items when quitting
• new API needed to follow the usability review in bug 349541
• moving the RecentItem icon code to GIO, and add API to extract the thumbnail

twitter: I’ve been using Twitter a lot in the past two weeks; it’s nice, it makes it easier to copy and paste a quote or a thought, and the 160 characters limit is an interesting challenge. As it’s been ages since I last wrote an application¹, I decided to start writing a Twitter reader/writer — using GTK+, Clutter and Tidy; without much thinking, I opened gvim and started writing code in C² — so, the obvious thing that happened was that I ended up writing a library yet again in order to use Twitter’s web API. luckily for me, libsoup has now a really nice API to work with; all you need is GET and POST to their RESTful API, retrieve the result, parse it through JSON-GLib, hide everything inside a new GObject and you have a wrapper around a web service. the application, you say? oh, I was sure I forgot something. well, it’s coming along — it just needs some work still.

1. lately all I’ve been doing was writing libraries [↩]
2. hey, that’s what I do for a living, it’s hard to switch off; plus, I could reuse some of the platform libraries [↩]

one thing that he noted is:

However, I still have the feeling that letting ~\.recently-used.xbel grow without control is very, very wrong. In my laptop, this file is about 5MB, which accounts for ca. 9000 files(!).

this is very true, but I feel it needs some context. when I first wrote the RecentManager code I only had the EggRecent implementation as a comparison; the old EggRecentModel had an hardcoded limit of 500 items stored per file. limiting on the number, instead of the age of an item inside a recently used file list did not feel right, so I thought about hardcoding a limit of 30 days — but stopped short of doing it because I realized that hardcoding limits at the toolkit level was not a good idea:

• application developers will not be able to change it in any way
• users will not be able to change it in any way
• system administrators will not be able to change it in any way

just to give a few examples: while I was still writing the RecentManager inside libegg, Alex Graveley was writing Gimmie. Gimmie had¹ a local document and application history that could allow you to go back in time of months; had I hardcoded a limit, the Gimmie developers would have needed a new implementation, defeating the purpose of shipping the RecentManager inside GTK+ to cut down the amount of code replication.

hardcoding limits is also something that makes it hard, or even impossible, for users and administrators to control; I might want a 30 days limit, but other might want a 90 days, or a 7 days — or even a 1 day limit. some might not even want to save the recently used files at all (think kiosks).

I don’t believe in strictly hardcoding policies in the toolkit; providing fallbacks is perfectly fine, but preventing people from actually having different settings is akin to convince everyone that you’re right and they’re wrong.

still, this doesn’t solve the problem at hand, that is the current lack of policy.

what I’d like to see is some process taking care of purging the old entries, using some key inside gconf, at the end of the session; gnome-settings-daemon would fit the role for GNOME, and other desktop environments using GTK+ could provide the same functionality². after all, gnome-settings-daemon should already flush the thumbnails cache — it wouldn’t be much of a complication.

1. and might still have — I haven’t checked it for a while now [↩]
2. if you’re not using a GTK+ based desktop environment you’re either using the same spec used by GTK+ so you can provide your own way of purging the cache, or you’re using another way to store the recently used files, so the size of the file saved/read by the RecentManager will not bubble out of control so easily — and you can still flush it yourself [↩]

thanks to Mathias and Openismus for being the local organization; thanks to Tim, Kris and the entire Imendio, for moderating the whole panels; thanks to Vincent and the GNOME Foundation, and obviously all the sponsors, for helping out in organizing and funding this gathering of hackers; and thanks to everyone that made these five days an incredible experience for me: you all really rock the GNOME community.

today was “wrap up” day. we got together in the room used for the presentations and summed up all our work during the various sessions of the week. it turned out that the amount of work, even though not reflected by the wiki page, was really enormous; the introspection guys worked a lot and now that they have received a lot of input, they are going to rework things and kick ass even more. apparently, Behdad decided that I would tackle the GL integration inside GDK — which, of course, I’d really like to do; the GL integration, and a GDK wrapper for the GLX_texture_from_pixmap (and the equivalent call for the other platforms) would obviously be the primary way to integrate Cairo 2D high quality drawing and GL 3D and hardware acceleration in a simple way. and this is a step forward the implementation of a scene graph inside GTK+.

in the meantime, I’m — as Ryan would put it — deeply recursing. it all started on tuesday, when I decided to start hacking on a real application with Vala using all the bits and pieces a modern GTK+ application requires: GtkUIManager, about dialogs, command-line switches. the application was supposedly going to read the new GTest framework reports, and allow comparing of multiple runs in a fast way. this, in turn, led to some bugs filed against Vala GTK+ bindings. working around these issues, I also found out that the libxml-2.0 bindings in Vala — which I need to parse the GTest report XML — require a lot of pointers usage and are, in general, quite sub-obtimal, due to the very C oriented API. while investigating on a substitute, I found out XmlReader — the cursor-based XML traversal API that .Net and other high-level languages implement¹. Thus, today at a coffe shop² I started hacking very quickly on a rough implementation of a XmlReader GObject class which, as of at this moment works quite nicely:

  XmlReader *reader = xml_reader_new ();
  GError *error = NULL;

  if (xml_reader_load_from_file (reader, “book.xml”, &error))
    g_error (“Unable to parse book.xml: %s“, error->message);

  xml_reader_read_start_element (reader, “book-info”);

  xml_reader_read_start_element (reader, “author”);
  author = g_strdup (xml_reader_get_element_value (reader));
  xml_reader_read_end_element (reader);

  xml_reader_read_start_element (reader, “title”);
  title = g_strdup (xml_reader_get_element_value (reader));
  xml_reader_read_end_element (reader);

  xml_reader_read_end_element (reader);

  g_print (“The author of %s is %s\n“, title, author);

  g_free (title);
  g_free (author);
  g_object_unref (reader);

and you’re done. at this moment, I’m cleaning it up and adding the gtk-doc API reference to the build³. I’m probably going to add the generic read() method, so that:

  while (xml_reader_read (reader))
    {
    …
    }

will work as expected. it’s, as usual, code replication — but I’m going to need it anyway, so it’s good code replication.

1. Even libxml-2.0 implements it, even though it suffers from the same issues of its DOM API, and it’s still not GObject-based [↩]
2. Behdad is right: a coffee shop without any Internet connectivity makes wonders with your productivity levels [↩]
3. When I write new libraries, I usually stub out the API and document it at the same time; now I started to add the GTest units before I even implement the API [↩]

on tuesday, Behdad and I started working on OpenGL integration inside GTK+. as stated multiple times on the Bugzilla entry, what we both would like is a Cairo-like integration of GL inside the available drawing systems in GTK+. in short: not a specialized widget like GtkGLArea, which would make it difficult — or plainly impossible without jumping through a long series of hoops. in flames. tied. and blindfolded — to integrate GL inside existsing projects; and not the incredible API dump that GtkGLExt is.

the design we mostly agreed on was a shared object inside GTK+, containing the GL context abstraction object, and two simple calls to delimit the drawing code, wait for vblank and swap the GL buffers. plus, an easy to use wrapper around the texture_from_pixmap extension, to allow drawing with cairo on a Pixmap and then have it pushed into the GL pipeline.

Carl arrived on wednesday, and partecipated at the scene graph BoF we held. the BoF itself was pretty straightforward: we read the slides that Havoc sent on the mailing list and discussed the various points. we all agreed on a lot of points — and we tried to define the problem space more deeply¹. being there, I could bring to the table my experience in the past two years² with the design and implementation of Clutter. some of the attendees were already familiar with it — something very satisfying — and I could expand some points in Havoc’s slides about Clutter that have been recently fixed or are going to be fixed in this cycle. the biggest point is that the scene graph should integrate with Cairo, in order to allow applications and people to gently merge both the 2D drawing of surfaces into a full 3D environment; I’ll leave to Carl to explain the Cairo side, because he’s obviously better at this than I am.

the operative result of the scene graph discussion was that Clutter emerged as an already powerful and established solution for this problem space, and given that it already nicely integrates with GTK+, we can work towards the common goal of making it “the GTK+ canvas”, outside the actual library so that it can grow unrestrained and experiment in new directions.

1. We did not always succeed in this, but the issue at hand is quite large and it’s understandable [↩]
2. It’s really two years? holy crap! The time really flew… [↩]

yesterday was devoted to the Imendio vision of a better toolkit, and how to get out of the hole we dug for ourselves with the current API/ABI contract - but others have written about it better than I could possibly do.

today was introspection day; Johan Dahlin showed the current state of the GObject introspection code by using a Vala widget, subclassing a GtkDrawingArea, from a Perl script — which was beyond cool. kudos to everyone that has been working on it.

today it’s also six years since the gtk+ 2.0.0 release, so happy birthday gtk+ 2.x!

Up until now, GtkRecentManager instances were available either via the gtk_recent_manager_new() constructor - which left the memory management duties to the developer - or via the gtk_recent_manager_get_default() which tried to do the right thing, by returning a singleton instance to be shared inside an application. The master plan was having the singleton attached to the GdkScreen to take advantage of the lifetime management of the screen done by GTK+ and cleanly dispose the recent manager when the screen was closed. This approach would have worked well, except for two tiny details:

1. if you change screen, gtk_recent_manager_get_default() will return a different instance
2. GdkScreen are never closed unless you do that explicitly.

So much for the master plan.

Thanks to Morten Welinder, who did some very appreciated detective work on it, it was decided to switch to a more common approach, with a static variable and a private synchronisation function that gets called when the main loop level reaches zero. What does this mean, for the application developer? First of all, two deprecations: both gtk_recent_manager_get_for_screen() and gtk_recent_manager_set_screen() are deprecated as of GTK+ 2.12 and should never be used again (the first evaluates to gtk_recent_manager_get_default() and the second to a NOP, if you ever decide to compile with GTK_DISABLE_DEPRECATED turned off); second of all, no more juggling around with the screen changes: multiple calls of gtk_recent_manager_get_default() will always return the same instance of the GtkRecentManager object - which you should never unref. Obviously, if you were creating your own recent manager instance with the gtk_recent_manager_new() constructor, none of this matters and you’ll have to handle the manager lifetime by yourself.

Another change I committed was the switch to the g_timeout_add_seconds() for the polling of the recent files storage file. Since the timeout was set to every N seconds I decided that the lifespan of my laptop’s battery was more important than having a millisecond precision on a stat() call. In other news, laptop owners around the world rejoice as one. Since every signal under GTK+ is emitted under the assumption that the emitter is inside the GDK master lock, the newly added gdk_threads_add_*() functions weren’t fit for my cunning plan of using the approximate timeout source; for this reason, I added a g_timeout_add_seconds_full() inside GLib and the equivalent code directly inside GtkRecentManager.

Otherwise, I might expect something like this for the next release.

And this has nothing to do with the fact that I’m a ViM user. No, really.

there are still a few missing bits (the icon for the shortcut is one of them) but it’s already working remarkably well. I’ll work toward implementing what’s left in the next few days, while I also fix some of the warts of the search support.

The file chooser now has a “Search” shortcut:

If you double click it, you’ll get a search pane:

Where you can search for “foo” and get the matching results:

Next stop: fix all the missing bits (#435343) and add a “Recently Used” shortcut showing the list of recently used files (bug #435342).

By the way: libbeagle has an incredibly nice API, whereas libtracker doesn’t. Please, Tracker developers: instead patching projects or writing a GTK+ widgets library which only new projects can use, focus on writing a nice, GObject-based API for all the existing projects out there. Pretty please, with the sugar on top.

Ubuntu: so, it seems that Dell signed on with Canonical to provide Ubuntu on their desktops and laptops. Good for the community, GNOME, Linux and, obviously, good for Canonical. Mark Shuttleworth will be rich (again), and without even having to resort to the patent on the hand-cranked XML parser.

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.

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.

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.