GNOME Performance Love Day just ended. Bugs were filed, patches applied, applications profiled.
A little step in the right direction for making GNOME faster.
Thanks to everyone involved: you rock.
Fastlove
Sunday will be the GNOME Performance Love Day!
The idea was first proposed on the #performance channel, after seeing that some of the initial performance related issues were simply lacking a bitof man-power, and weren’t that difficult even for a beginner; mainly, at this point, lazy loading of shared modules inside the platform libraries, and the integrity checks inside private functions. Also, lack of profiling data on various machines/architectures is another issue when doing performance evaluation and regressions; if we can gather enough data on a GNOME release, on multiple platforms, we can actually become aware of regressions (in the worst case) or brag about us being faster in the next release (in the best case). As Federico wrote, the problem with performance is that you can’t simply make ${FOO} faster: you need to know how fast is going now, and how much your patches are actually making ${FOO} faster – or if they do at all.
So, if sunday you feel in the mood for profiling, hacking and learning more about the GNOME platform, jump aboard!
Dictionary Applet/2
As I said on the gnome-utils mailing list, the GNOME Dictionary codebase sucks.
Well, it sucks to the very end of it.
It really shows its age (it’s more than 5 years old), and suffers of what I’m used to call design by accretion. This particular technique of software design works like a black hole: particles are attracted to the singularity, and form the “accretion disk”, which is nothing but a big mass of… er… mass, graviting around, attracting other mass, and accelerating – thus getting hotter and hotter – until it eventually hits the event horizon. In software, it works the same way; new code is added, and it becomes relevant up to the point of becoming critical. The code becomes a little bit ugly, and it attracts other ugly code in order to make things work and to add new features. Time passes, and the codebase becomes a uglier mess at each iteration. At one point, everything simply collapses, because one of the “oh-so-hackish” portions of code simply passes the point of being understandable by any human being – including the original writer. Also, the overall entropy of the software increases, because no-one is smart enough to understand the code, let alone sanitize it; this is what I call the “design by accretion runaway syndrome”. At this point, the only option for a developer is to toss everything out of the window in disgust, and begin from scratch; which means time, effort, and skills needed for features and bug-fixing are instead spent on rewriting stuff. One way to stop a “design by accretion” before it reaches its “runaway syndrome” is to check for hacks, kludges, ugly portions of code and exterminate them at each iterations. Hacks are what they are: they might be clever, well-thought or a demostration of coding skills; but they are hacks nonetheless, and the shorter they live, the better codebase will result in the end.
The dictionary application and applet is the best result of this particular software design “technique”; not only the high-level code is a collection of circular references and inclusions – also the low-level implementation of the dictionary protocol has become hackish enough to include at least two API, one of which is an almost complete implementation of RFC 2229, while the other is like a remnant of a previous implementation.
I tried to put a thin GObject layer around it, in order to avoid having to write my own implementation of the dictionary protocol; so far, the results are discouraging. Ergo, the best solution is to throw away the low-level stuff, create a new, GObject-oriented implementation of the dictionary protocol, and build up from there.
In the meantime, I’ll have to pass a couple of exams, and begin porting the BookmarkFile and RecentManager/RecentChooser code under GLib and GTK; also, the FileChooser code should be adapted to support recently used files in OPEN mode, and the shortcuts be saved using the BookmarkFile object inside a default location – something like $XDG_DATA_HOME/desktop-bookmarks/gtk-shortcuts.xbel.
Thumbnails
Today I had a couple of hours to spare at the university, so I decided to implement a couple of items in my “to do” list.
The first is the creation of a simple function for adding items to the RecentManager – ideally, it should require just a URI and retrieve the data where possible. For the MIME of the resource, I used the xdgmime library, which is also used by GTK in order to interface the RecentManager code to the FreeDesktop.Org shared MIME informations; the application_name, application_exec tuple is filled with the default program name (as supplied by GLib). This should cut back some of the API complexity, and be useful just for the local file case. If you are dealing with remotely-placed resources, you should really use gnome-vfs, and fill up these meta-data fields by yourself.
The other item in my list was the thumbnailing support. James Cape did a wonderful job, implementing the fd.o thumbnailing specification inside a libegg module (for his IconChooser widget), so I just linked his code, and added an appropriate function for the RecentInfo object.
Now, both the RecentChooserMenu and the RecentChooserWidget can display thumbnails of the resources.
Profiling GMarkup – take 2. After having profiled GMarkup with a medium sized file (under 1000 bookmark entries, approx. 400KB), I’ve set off to profile it using a >1MB file, in order to get some more experimental data on the edges of GMarkup. During the last GTK meeting, Federico suggested that GTK could read the GConf XML and retrieve some of the preferences from there – instead of making GTK depending on GConf (which would mean making it depending on ORBit2, libxml2 and others). I’ve expressed some doubts about this operation; mainly because reading the recently used resources file one in a while is not so intensive: after all, we are talking about one thousand entries at most (I do clean my recent documents once in a while), while a common $HOME/.gconf directory spans typically more than 1 MB on disk. The preliminary figures I gathered last night are that parsing a 1.5 MB file with GMarkup will take up at most ~2.5 seconds with cold cache and ~1 second with hot cache (on a test with 10000 sequential runs). Federico is trying to shave off decimals of seconds from the FileChooser – a 2 seconds delay just for reading the GConf database is just wrong; also, what if the configuration is not local or user-defined? We can’t read (let alone modify) some of the settings if the system administrators locked them down. So, in the end, I think that this is just not the way to go.
Jody Goldberg proposed the creation of a KeyFile-based configuration system just for GTK; this would bring GNOME into the exciting nineties, right at the side of Windows 3.1 with its .INI files.
While I wholeheartedly agree with Federico and Jody that GTK should be able to save some of its state data, I also feel that both GConf and a INI-like solutions are not the best one for this issue. I don’t know what to propose in place, though, so I’ll just shut up for the time being.
RecentChooserWidget/1
The EggRecentChooserWidget code is in CVS since a bunch of minutes, complete with a context menu allowing the removal of items from the list, the ability to add a custom RecentManager instance instead of using its own (still requires some polishing, but the interesting bits are there), and filtering based on a custom function. Also, I’ve fixed a nasty bug in the parser library that left garbage at the end of the storage file when removing items.
The next step is to allow the creation of RecentManager objects (maybe using runtime loadable modules) so that Gnome could use a GnomeVFS enabled resource monitoring in order to track location/file changes. This would require the implementation of RecentManager as a GInterface, as a plausible approach.
Anyway, now I’ll work on an applet/technology demonstrator, in order to have more to show to the Gtk people.
RecentChooserWidget
I’ve pretty much finished my EggRecentChooserWidget widget, which (I noticed) is roughly modelled on the Document History window of the Gimp:
Also, as you can see, I’ve enable the filtering code, so that you can now filter the contents of the recently used resources list on the fly:
Display all recently used resources.
Display today’s recently used resources.
The EggRecentChooserWidget will also have a dialog window (EggRecentChooserDialog) and a button widget (EggRecentChooserButton), much in the same philosophy of the GtkFileChooser widget set. In the source tree I’ve put a simple test program which basically recreates the same Open Recent menu of the Gimp (except for the little preview, which is replaced by the icon bound to the file’s MIME type).
There are some rough edges I’d like to address before committing the code, but I plan to have the widget and the dialog inside CVS by this week.
On a related news, I’ve began porting the panel to the RecentChooser and RecentManager code; other than changing the Open Recent menu widget with the EggRecentChooserMenu one (complete with a menu item launching the EggRecentChooserDialog dialog in order to display all the recently used resources), I plan to add a list of recently used applications inside the Run Application dialog; using this list as a default, we could hide the currently used entry.
Post-Triage
I’ve spent the last five hours triaging the open bugs of recent-files. Some of them were in bugzilla since 2003, and many were marked UNCOFIRMED.
First of all, I scanned the bugs with patches, and created a first batch with the most clean patches I found; then, I triaged the uncofirmed bugs. Then I closed the only report which was not a bug.
On other news: ph34r m3, f0r I h4v3 4 CVS 4cc0unt
(not for writing yet, but I assume I’ll need time for that).
I hope to commit the first batch tomorrow – now I’m completely spent.
Back from GUADEC
Yesterday I came back from the GUADEC 2005 in Stuttgart.
It has been freakin’ awesome! The talks, the people, the organization… Simply amazing.
I enjoyed every talk I attended: the Cairo talk by Owen Taylor; the Keith Packard’s talk on improving X; Davyd Madeley’s talk on the future of panel applets; Seth Nickell’s talk on usability.
I found the keynotes by Miguel de Icaza and Mark Shuttleworth very entertaining, and aggressive; I think that the Gnome community as a whole should be much more aggressive, in terms of market acquisition, if we want to achieve the “10×10” (10% of market share within 2010) objective. As for what I’ve seen in these two days, we can make it – with a little help from our competitors, obviously.
I met Federico Mena Quintero, and we talked about implementing a bookmarks/recently used files manager in Gtk – basically, shifting my Gnome Desktop Bookmarks project down into the dependency stack. This should get rid of the recent-files stuff in libegg, and should provide the correct API for others to use (especially Nautilus). At the hackfest I put up a mockup (actually, it’s an almost complete program in Perl using my development trunk of the recent-files Perl bindings) of what should become the GtkFileChooserDialog for recently used items.
Here’s an obligatory snapshot:
As I sayed, it already works; you might want to download it from here; you need the latest CVS snapshot of the Gtk2::Recent module from the Gtk2-Perl’s CVS.
What I plan to do is to rewrite the entire recently used management (using the desktop bookmark specification for the items storage), create a dialog like the one above and a widget. The recently used objects would be stored by the GtkFileChooser class, so no interaction of the developer should be needed; applications might decide to implement a “Open Recently Used…” menu item which creates the GtkRecentChooserDialog dialog instead of filling a (sub)menu.
Also, an applet/viewer/nautilus extension should be available, in order to always have the recently used items on the desktop.
Bookmark Spec
I’ve sent a draft for a desktop bookmark spec on fd.o, and it got reviewed – mostly by the KDE people, that got already a standard way of storing bookmarks across the desktop.
If it reaches the common approval, I’ll apply for a CVS account on freedesktop.org’s server.
Meanwhile, I’m working on the implementation of the spec on the Gnome side: I already have a model/viewer approach set, and now I’m writing a generic XBEL object using GLib. It’s quite fun, I must admit. Well, it’s fun since I’ve found an implementation of an XBEL parser using libxml2 inside Galeon.
I hope to have a Gnome platform library for the bookmarks spec ready before GUADEC arrives…
Gnome Desktop Bookmarks
On Gnome Live there’s an ongoing discussion about recent files and bookmarks in Gnome.
In the last two weeks I’ve been designing and writing a platform library for Gnome which addresses the points made on the Wiki, on Bugzilla and on the mailing lists (as I said here).
It’s called libgnome-bookmark and implements the concept of a generic “bookmark”; a bookmark is everything pointed by a URI, plus some meta-data. The library comes with two objects: GnomeBookmarkItem – which is the representation of the bookmark – and GnomeBookmarkModel – the monitor of the bookmarks storage.
You just add and get items to and from the model, similarly to the current recent-files stuff. Plus, the model has the ability to support custom filter and sort functions, in order to get what you want, the way you want it. Bookmarks also might be registered by more than one application (so that you have the ability to create per-application bookmarks) and might belong to various groups (so that you can have classes of applications using the same bookmarks).
Recent files and desktop bookmarks are handled simply by defining two groups in the specification.
In my opinion, this solves the bookmarks problem, and the recent files issues in a single move.