Vectacity as CSS

Coloured boxesDavyd Madeley made an interesting suggestion for redesigning the theme format.  Assuming, as seems likely, we end up using Clutter, there’s no need to specify the structure of a window, which would need SVG.  After all, all windows have a basically similar structure.  Instead, we could style any item on the window usinga CSS file, parsed by libccss.

Don’t want a titlebar?
#titlebar {
height: 0;
}

Want a red background on the close button?
button#close {
background-color: red;
}

And so on.  I think this is an interesting idea because it seems comprehensive enough to capture all the problems we face in theme design.  I’m wondering whether it’s perhaps more powerful than necessary and whether it could cause themes to be able to be disruptive, though.

Photo © Sarah G, cc-by.

Squib of the day: SVG theme support

Brutality against mosquitoes. GNOME bug 107012 brings up the perennial question of SVG support in themes, otherwise known as Vectacity. We’ve already covered this in a few places, but I think it may be worth mentioning here the two main reasons SVG-based themes is a good thing (there may be any number of other reasons they’re a bad thing, as well):

  • SVG is now a clear standard for vector graphics.  So theme artists will be able to reuse their existing knowledge about SVG when coming to design Metacity themes.
  • It means we can remove large amounts of code from Metacity and use whatever SVG library we end up depending on instead.  (There is a heavy presumption that this library will be GNOME’s own librsvg.)  Having less code around is generally a positive thing.

However, stretching SVG to meet our needs, or indeed stretching librsvg to meet our needs, rather negates the second benefit: it’s possible that including CSS will let us do what we need, but it’s also possible that librsvg is not clever enough to let this happen without so much coaxing on our side that we may as well have written an entire SVG library of our own, which is something we’d like to avoid.

If Vectacity ever becomes a reality, it certainly needs to be possible to convert a v1 or v2 theme to Vectacity automatically.  This is partly for the theme artists’ benefit, but also because it means if a Vectacity-enabled Metacity finds itself having to load a v1 or v2 theme, it can do the conversion by spawning a separate program rather than having to keep the legacy code for reading v1 and v2 themes lying around, which again negates the second benefit.

Forthcoming versions of SVG are specifically considering use by window managers, but we may have to wait a while for them to get into a usable format. It may be best to WONTFIX this one, at least until v4.  On the other hand, the two benefits given are indeed important benefits, and I’d like to see it happen sooner.

Photo © freebird (bobinson|ബോബിന്‍സണ്), cc-by-nc-sa.

Squib of the day: line weight

Empty Victoria Line Tube TrainAt present all lines are drawn at the same thickness.  However, some people such as partially-sighted users require particularly thick lines .  GNOME bug 86040 suggests that the line format be extended to give the width as a fraction of the current icon height.

Since this is a change to the format, it must appear first on a branch. This bug actually predates v2, but wasn’t included in that version because it wasn’t marked as blocking the v2 tracker bug.

If this would still be useful to anyone, it could certainly still go into v3 of the theme format.

This bug is perhaps the first place where the use of SVG was suggested as a workaround for having to add new features.  Elsewhere, someone also suggests a novel idea of allowing themes to ship TrueType fonts which contain unusual glyphs, in order to have access to another well-defined vector graphics language.  Of course, this would be subsumed if we decided to use SVG.

Photo © Callistobreeze, cc-by-nc-sa.

Policy about theme versions

a day's workMetacity has a policy about enhancements which require changes to the theme format.  Metacity has to be both backwards and forward compatible.  In other words, it’s not enough that a later version of Metacity can run with themes intended for an earlier version.  Earlier versions must also be able to run with themes intended for a later version.

In order to accomplish this goal, themes are kept in a file named metacity-theme-n.xml, where n is the number of the version of the theme format.  A theme which supports a version should also have files for all the preceding versions, and Metacity will read only the highest version found which it can understand and leave the rest alone.

This works.  However, if there were hundreds of theme versions, it would become unwieldy.  So we save up enhancements and commit a bunch of them all together.  The only time this has happened so far was in October 2006, when v2 was introduced.  (Not many people are using v2, even over three years later, and even though users evidently want the features it brings.  This may be because theme artists aren’t sure how to create them.  One of the advantages of a theme editor would be that it would be able to take care of creating valid intermediate versions for you.)

Some enhancements still being suggested will involve changes to the theme format.  For example, Screwtape has suggested a special window state representing windows which are running as root, so that they can be drawn using a different colour or something.  Enhancements such as these will all have to be made on a branch and merged all together at some time in the medium future, perhaps next year.  I have made a category to group posts about such enhancement requests into.

One of the big questions about v3 is whether it should be SVG-based– the so-called Vectacity format.  This will quite possibly win us very little for the extra effort that will be required to mould SVG into a format which can adequately represent window decorations, so Vectacity may not happen in version 3, or at all.

Photo © Tim McFarlane, cc-by-nc-nd.

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.

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.