Metacity and D-Bus

Zarko Drincic - The Electric Bus (Awarded by National Geographic Magazine) GNOME bug 531512 suggests that Metacity should have a D-Bus interface.  On the face of it, this is a good idea.  However, the problem lies in the existing EWMH specification, which allows a program to request operations from a window manager– simply put, it’s pretty much exactly what a D-Bus interface would be, but it already exists.  If we also exposed a D-Bus interface, even one called “org.freedesktop.WM” instead of “org.gnome.Metacity”, we wouldn’t be gaining anything we don’t already have, and then people would begin using it and their programs wouldn’t be compatible with other EWMH window managers.  So every WM that implements the EWMH would have to expose the same D-Bus interface, which sounds like a lot of work for not much return.  On the other hand, we could have a separate program which exposed a D-Bus interface which translated the methods into EWMH messages, and which could be used with any EWMH window manager.  Would that do as well?  What do you think, gentle reader?

Photo copyright Zarko Drincic, cc-by-nd.

Half-finished code finishing marathon time

I have several half-finished bits of code lying around.  I think I’ll make an effort to merge them in, at least in test branches, to see what people think.  (When we get a DVCS, this will be easier.)

  1. Veracity, a test suite.  This is about two-thirds done, but will require a bit of autotools magic to link into the main build process.  I may need some help with that.
  2. Window matching: something to remember window positions across sessions.  There’s been a few requests for it recently (most recently , Launchpad bug 311615).  We’ve always said we wouldn’t do this, but maybe there’s no harm done in trying it in a branch as an experiment.
  3. Opacity, a simple WYSIWYG theme editor.  About a quarter to a third of it is written.  Probably would be best to make this a separate project.
  4. Actions.  The idea has often come up (e.g . GNOME bug 345233) that if there’s something you can bind a keystroke to, you should be able to put it into the window menu or make it a titlebar button or whatever.  This may be over-configurable, but there may be advantages of a simplified architecture in making it possible at all. There’s experimental code to do this, but it’s about half done.
  5. “Cringe”: how much can we avoid keeping in memory at once?  This is an answer to what I think is our oldest current bug , GNOME bug 144242.  Saving a few bytes here and there per window can really add up.  I’ve done a small amount of playing around with this, but more is needed.  Having Veracity working will really make this easier because then we’ll just be able to run a stress test inside valgrind.

Gentle reader, which should be moved out of Metacity Labs first?

Take that, Descartes

Die mosquito

Listen to this.

Here are two ideas with which I broadly agree:

  1. A theme format is less useful without a program to edit the theme files.  Having to modify XML by hand is not a prospect which most people relish.
  2. If there’s to be a third version of the Metacity theme format, it would be helpful if it was based around SVG, since theme files describe vector graphics and SVG has become a standard for such files.  It must not however sacrifice the ability of our current format to prevent themes making the computer unusable.

Back in August, I added simple SVG support to a branch of Metacity that I named “Vectacity“.  My project was shelved because of more urgent business elsewhere, but Iain has also done some work in this area.

In order to play around with the Vectacity format, I have since built a very simple version of an editor.  However, I have run into a theoretical problem for which I seek your insight, gentle reader.

There are certain problems which a theme file has to solve which are not faced by ordinary vector graphics.  One of them, which is easily answered, is the question of how to add the buttons which are currently in use to the titlebar, when this is not known in advance.  Another simple question is how to represent colours from the desktop theme.  A more serious problem is that the width and height of the window is not known in advance either, and nor is the width of the window’s title.  Metacity currently solves this problem using a simple expression language in which these variables can appear as terms.

However we solve this problem in Vectacity, it’s not a problem to modify the coordinates of elements according to the size of the window: the SVG in each theme file is going to have to go through a cleaner anyway before it hits the screen.  Some possible solutions include:

  • reuse. Use the existing expression language: <rect x="3" y="10" width="{w-3}" height="{h-3}"/>;.  This is how Vectacity currently works.  But this means we’re using the SVG namespace but including invalid SVG.
  • vectacity:expr. Mark the attributes which need recalculating, but leave precalculated values in the file: <rect x="3" y="10" width="997" height="997" vectacity:expr="width:w-3; height: h-3"/>.
  • stretchyspace. Subvert the concept of Cartesian coordinates by entering stretchyspace.  In stretchyspace there are 1001 coordinates; addresses below 0 and above 1000 are undefined.  Addresses between 0 and 300 are translated with respect to the left or top, addresses between 700 and 1000 with respect to the right or bottom, and addresses between 301 and 699 are as close to the centre as the address is close to 500: <rect x="3" y="10" width="997" height="997"/>.

Stretchyspace neatly keeps us SVG-compliant, but it’s a much less powerful representation than the existing system.  It’s true that the power of the existing system is rarely used to anywhere near its full extent, but there are existing behaviours which stretchyspace cannot represent.  In particular, titlebar decoration often places non-text graphics with respect to the length of the title:

Examples of the same titlebar shown in three themes
Fig. 1: Same titlebar, three themes.

The first line, for Crux, shows a graphic which has been pushed to the right by the length of the titlebar text.  The second, Atlanta, shows the window icon which is centred along with the titlebar text.  The third, Human, involves printing many copies of the titlebar text; this can be simulated in SVG using styling, but the other two are more of a problem, since they involve non-text participating in text flow.   If we’re using an expression language, this can be handled using coordinate substitution, but if we’re using something like stretchyspace, it will need to be handled in the SVG itself.  Non-text elements appearing in text flow may be possible in SVG1.2, but I don’t know how to do it in SVG1.1.  (Is there a way?  Do you know?)  For this reason, stretchyspace is not a useful answer for the representation of relative coordinates.

Another question we need to consider is whether external SVG editors should be usable.  There are many fine SVG editors around, such as Inkscape.  Allowing the use of one of these, with a tool which extracted SVG data and spawned an external editor, would permit people all the power of an existing application and save us the trouble of writing a new one.

If we are to use an external editor, though, we must consider how relative coordinates may be represented whilst within it.  One obvious conclusion is that we could use stretchyspace coordinates, but the same problems with title placement exist in this case as well; they could perhaps be worked around, hackily, since the title field in a saved SVG has a known length.  Other possibilities include using using the vectacity:expr field and copying its value into and then out of the description field of the relevant object, at a severe cost to usability.

If we are not to use an external editor, the value of using SVG at all becomes a little reduced.

Photo by kozzmen, cc-by-nc-nd.