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.

2 Comments

  1. Screwtape
    Posted March 5, 2009 at 5:25 am | Permalink

    I think the problem with v2 themes is that the add a few convenient features (constants and variable-radius borders), but require a lot of extra boilerplate (all those extra title-bar buttons). Of course, another issue is that a large number of themes don’t need anything more than what the v1 format provides.

    A potential wish-list item for the v3 theme format would be to take a leaf out of the HTML/CSS book: have built-in defaults for everything, allow the theme author to override some of them, and have a well-documented system for how overrides cascade to affect other things. For example, if I only define a normal window style, it’s a good guess I want every kind of window to use it. If I define “normal” and “dialog” styles, it’s more likely that “shaded” and “maximized” windows should follow the “normal” style, but “modal_dialog” should follow “dialog”.

    This sort of cascade is what I was getting at with the complicated list in bug 565913 -

  2. Posted March 5, 2009 at 5:51 am | Permalink

    Someone (can’t remmeber who) was discussing the use of SVG for themes in Metacity on irc://irc.freenode.net/svg with me recently. As a result I added a requirement to the “SVG Layout: Use Cases and Requirements” document:

    http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html#template

    which will be published as a first draft soon. We (the SVG Working Group) discussed this particular requirement at our recent face-to-face meeting a couple of weeks ago, and there wasn’t consensus on having this as a strict requirement for our Layout module. Instead it’s going to be a “maybe” requirement (i.e., if we can support it easily, we will, but it won’t have a big influence on the design of the upcoming SVG layout capabilities). However, the use of the other SVG layout features (such as layout containers) that are proposed, in conjunction with some custom templating mechanism, could well be sufficient for your needs.

4 Trackbacks

  1. […] 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. […]

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

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

  4. […] press them– should fade in from the non-prelit state.  This was originally said to require a change to the theme format, but in fact I can’t see that it does: any theme which defines a prelit state for buttons can […]