More failed experiments in theming

Underwater Feet

  1. Not very surprisingly, replacing horizontal and vertical lines with rectangles doesn’t speed things up detectably.  (There once were systems where this made a difference, but I think GTK is probably clever enough that this doesn’t matter.)
  2. More interestingly, plotting the title to a monochrome bitmap, and then setting that bitmap as a stipple and drawing a filled rectangle instead of drawing the title also does not speed things up detectably.  I thought avoiding a Pango hit for some common themes which plot the title more than once might make a difference.  (Human plots the title of the active window four times, for example, and is the slowest common theme.)

(I am working on things other than this sort of thing, it’s just that this is producing results which are interesting to talk about and other bugs and problems aren’t so much.)

Photo © kagey_b, cc-by-nc-nd.

Squib of the day: extend plugin possibilities

For once, this isn’t about an existing bug– well, there’s a tenuous connection to GNOME bug 311428.

Several of the recent squibs have resulted in the observation that an external script could be made to do the work.  This is true for responding to keypresses, but for problems such as performing some action whenever a window opens it gets a bit harder– the external script must run all the time and either monitor X events or, as devilspie does, get libwnck to monitor X events on its behalf.

It might be a better idea if Metacity (or libwnck) could be given a list of commands to run when windows open, and possibly on other events, to make writing plugins easier.

The (fast!) default would be the empty list, of course.

Another event which it would make sense to be able to tie plugins into is window role change, so that a window-matching script could learn automatically.

It would also be sensible to allow programs to be executed when mouse buttons other than the main three were pressed (so you could launch an Exposé clone by pressing the shoulder button, for example).

Photo © Katie Sutton, cc-by-nc-sa.

Version 3 themes

Mosquito biteSeveral ideas have come up recently about extensions to the theme format.  Here are some rather disjointed notes about the problems we face here.  I apologise for their fragmentary nature.

According to policy, incompatible changes must be made all at once with a new version of the theme format, to preserve backward compatibility.  (This has only happened once so far, so the only versions of the theme format to exist are v1 and v2.)

One feature I’d like in a new theme format is to have everything in the same file.  At present we have almost everything together except the pixmaps.  I’d like to put them in the same file; rather than using base64, we should use xpm for this, which gdk supports out of the box.  That way, you can have just one single file to download.  Also for ease of sharing, it should have the theme name in the filename this time, rather than the directory name.

As to the format of the new files, there’s a strong suggestion around that they should be SVG.  Such a format could either be designed from the ground up or be an evolution of the current system.  However, I believe that what is needed is a clear upgrade path, and so we need an evolutionary approach.  If we can build a conversion utility to convert v1 and v2 themes into v3 themes, then not only will people be able to work with all their existing themes immediately, but we can support only v3 in Metacity itself and call the conversion utility when a theme is encountered which only supports v1 or v2.

One problem with both the evolutionary and revolutionary approaches is that there are ideas in Metacity themes which cannot be expressed in SVG: for example, some themes place a graphic to the left or right of a piece of text of unknown length.  I have spoken informally to a member of the SVG Working Group who has confirmed that this is not possible in current pure SVG designs.  However, it is possible with scripting.  So we can consider a simple refinement of our existing coordinate-expression system as a form of SVG scripting system, where we set the dimensions and positions of elements with respect to other elements.

Something like this could be achieved using librsvg by building a text buffer containing the XML with sufficient whitespace to the left of every decimal.  As our homegrown scripting language was parsed we’d build up a set of pairs of (char*, expression) and every time a frame was drawn we’d simply write the new value into the buffer.  It would obviously be simpler if we could modify the parsed form of the SVG inside librsvg, but I don’t believe it allows that.  More importantly, we need to be able to find the widths and heights of various elements, especially the title, in order to position other elements, and I don’t believe librsvg allows us to read its parsed form either.  (Do you know otherwise?)  If not, where can we go?

Of course we could possibly keep doing it in house as we do now, but use an SVG-like syntax instead.  Effectively we’d be writing our own SVG library.  This is not exactly a cause for rejoicing.

Photo © James Jordan, cc-by-nd.

Some of the tools

Buttermere Star TrailsHere are some of the tools that ship in the tools directory of Metacity:
is the script that produces release announcements in both text form (for gnome-announce-list) and HTML (for posts like this one).  It needs some polishing.
puts up an editor for a ChangeLog entry, then commits current changes.  It used to be far more complicated, but now it’s merely a wrapper around a couple of calls to moap.  Stable.
given an attachment number on GNOME Bugzilla, checks out Metacity trunk, downloads the given patch, applies it, and compiles.  Stable, but it would be nice if it could pick up the author’s name and email address for the ChangeLog too.  That will probably have to wait for a scriptable GNOME Bugzilla.
is supposed to build personal package archives for Launchpad with nightly builds in.  It doesn’t work at present.
is our release script; it helps prepare the NEWS update from the ChangeLog, distchecks, builds, and uploads, but doesn’t actually run the update script on the server.  I did think of replacing this with ShipIt at some point, but their model is too different from ours.  Stable.

There’s also which isn’t shipped, and produces the Metacity Journal, and is being gradually replaced by a more general version in Perl called ProjectJournal. Also, the Perl module Flickr::Embed grew out of the same project, though it isn’t yet in use.

Photo © Horrgakx, cc-by-nc-nd.

Squib of the day: Remove alt-tab entirely

Even super heroes need a day offIn GNOME bug 570079, someone suggests throwing away alt-tab entirely to replace it with an external program, specifically superswitcher.

Of course, you can already do this by disabling the ordinary alt-tab action and then assigning superswitcher to be one of the custom commands, but I think they want it shipped that way by default. I suppose it might be interesting to be able to have alt-tab in a separate process, if you wanted to save memory and your computer was fast enough that it wasn’t too slow to start up.

Photo © kagey_b, cc-by-nc-nd.

2009-02-02: Metacity Journal

The Peahen, St Albans. Photo by Gary Houston, public domain.
It’s that journal thing again.


Checkins on branches/rpnparser

Checkins on trunk


Photo: The Peahen, St Albans. Photo by Gary Houston, public domain.

Sorry for the silence

Banshees on the WindSorry for the silence of the past few days; I’ve been working on a possible fix to the theme rendering code, after the test suite told me that the part which calculates the value of expressions was a bit slow.  Currently it tokenises during theme load but parses every evaluation.  I thought that if I parsed it into some stack-based form on theme load, it might take slightly longer to load a theme, but everything would draw faster by just evaluating the stack-based version.  (I also took the opportunity to do all floating-point arithmetic using scaled integers, because I’m stuck in 1988.)

In practice, though, the results have been disappointing: it only seems to have saved a few microseconds here and there.  So it’s probably not worth the disruption of merging it, though it does also make the code 584 lines shorter, mainly through its use of a GScanner instead of tokenising in house.  I think it also makes the code a bit easier to read.  I’ve put the patch up in case anyone fancies suggesting how it can be sped up a bit further.

(One optimisation that the existing version does that the patch doesn’t do is evaluate constant expressions at theme load time– so if you have Fred+1 where Fred is a constant equal to 2, it will store just 3 and not bother doing the evaluation.  I’m not sure whether that would give much extra speed to the new code.)

Still, experiments are worth doing even if they fail!

Photo © Dead Air, cc-by-nc-sa.

Metacity 2.25.144 released

St.Albans Abbey at TwilightWhat is it ?

  • Metacity is a simple compositing window manager that integrates nicely with GNOME 2.

What’s changed ?

Thanks to Matthias Claesen, Matt Kraai, Elijah Newren, Owen Taylor, and Thomas Thurman for improvements in this version.


  • David Planella (ca), Jorge González (es), Mattias Põldaru (et), saudat mohammed (ha), Yuval Tanny (he), Gabor Kelemen (hu), Onye, Sylvester (ig), Changwoo Ryu (ko), Raivis Dejus (lv), Kjartan Maraas (nb), Daniel Nylander (sv), Fajuyitan, Sunday Ayo (yo), 甘露 (Gan Lu) (zh_CN)

Where can I get it ?

  • b7f51a8144584f51434b8775216bc2c5 bz2
  • 9ef9e03e4b961b1e694223a67f1ebe8b gz

Photo © bluebus, cc-by-nc-nd.