Themes v3 – Page 2 – …for the adult in you

Towards a third version of the theme format: some design goals

When we add features to the theme format, they must be added all in one go for reasons which were explained earlier. We are currently on version 2 of the theme format. In case there is ever a version 3, here are some of our design goals. Not all of these may necessarily be met when and if it happens. These are not in order of importance.

Standard format. If possible, it should use standard file formats rather than custom ones. This helps build tools, it helps code reuse, and it helps users learn the format.
Editable. It should be designed such that it’s possible to write a theme editor which is easy to understand and use.
Delegation. It would be useful if at least some of the code to parse and render the theme files was in a pre-existing library rather than being part of Metacity itself.
Shareability. It should be at least possible to use the same theme format with various other window managers, which could perhaps be helped by keeping the code in an LGPL library.
Single file. There should be a standard format for keeping all files associated with a theme in a single file, at least for both distribution and installation. This will save the end user from ever having to deal with tar or zip.
Subthemes. It should be possible to write a theme which inherits some of its attributes from an existing parent theme.
Named colours. It should be possible to give identifiers and descriptions to a subset of colour constants so that the theme artist can override them on the fly. (This is perhaps already solved given that we can use colours out of GTK themes.)
Well-defined metadata. There should be visible metadata, including licence identifiers, which can contain a list of all authors as a theme gets remixed. Theme editors should make it easy to keep this up to date. In keeping with our use of standard formats, we should probably use Dublin Core for the fields and perhaps the same identifiers that DOAP uses for licences. The casual theme artist should never see any of this, of course.
Upgrade path. It should be possible to convert themes in version 1 or version 2 format to version 3 format automatically. Conversion from other WM’s formats would be a nice touch.
Minimum power. We don’t need to be able to do everything that v2 can do. We do need to be able to do everything that is commonly done in v2. (For example, v2 allows you to have a title “centred” ⅔ of the way across the titlebar. This has probably never been used, and it’s no big problem if v3 can’t do it. If it can’t centre the title in the middle, that’s more of a problem.)
Maximum power. It should not be possible for the theme to get in the user’s way. For example, it should not be possible to write a theme which obscures the contents of windows; otherwise it would not be possible to switch away from it. Neither should it be possible to solve the Towers of Hanoi in the theme engine. People have better things to do with their time.

Your thoughts on these and your suggestions for other goals are welcome, gentle reader.

Vectacity as CSS

Davyd 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: named colours

GNOME bug 121866 would like a way to set drawing colours according to palette entries in bitmap images in the same theme, as well as giving literal RGB values or giving a reference to a GTK colour. It is suggested by the reporter that this could be done with the XPM format, which allows colours– or rather, entries in the palette– to be named instead of specified: foreground, for example.

This is quite a vague requirement. Because this requires a change to the theme format, it must be committed first on a branch. However, using bitmaps in themes at all is somewhat deprecated.

A useful variation on this idea would be to allow a set of colours to be undefined within a theme, which could be done by extending v2’s support for colour constants, and then allowing other sub-themes to specify only the missing colours. Or perhaps the user could choose the colours for themselves as parameters to the theme; this part we could even do already with no change to the theme format, by adding a new GConf key which allowed redefinition of colour constants in the current theme. You can imagine a standard utility which would read the theme file and give the user colour pickers for each constant, then set the values in GConf.

This would then bring us back to the original problem and might require us to be able to change a specific colour in bitmaps as appropriate; alternatively, we could just say it was one more reason why bitmaps in themes are a bad idea.

Photo © Bernat Casero, cc-by-nc-nd.

Squib of the day: SVG theme support

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: Special frame style for warning dialogues

GNOME bug 102548 suggests that warning dialogues should have a special frame style, and it’s suggested that this could look like safety tape wrapped around the edge.

This is not unlike the special frame style suggested here for root windows. However, while there’s already a way for the window manager to tell whether a window belongs to the superuser, there’s currently no way to tell whether a window is a warning, so this would need a change made to the EWMH and then need all the toolkits fixing to use it. It’s thus rather nontrivial, although it may still be worth it if it helps users.

Because this requires a change to the theme format, it must be committed first on a branch.

I am seriously entertaining the idea of doing away with the window and frame_style_set tags in v3 of the format, and just using tags on frame styles such as maximized, shaded, focused, unfocused, root, warning, modal, and so on, with some well-defined and intuitive rule about how to break ties:

<frame_style geometry="foo" tags="border focused maximized"> <piece position="title"> ...

Squib of the day: line weight

At 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.

Policy about theme versions

Metacity 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.