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.
Photo copyright © bitzcelt, cc-by-nc-nd.
I think all these goals are laudable and worthy. However, I have some comments:
1. Standard format: I think this is going to be the most difficult to achieve overall, although picking standard formats for various components should be fairly simple (ZIP for archiving, PNG for static images, etc.)
2. Editable: This goal is a black mark against any generic cascading system such as CSS uses; creating a user interface that *depicts* the cascade is fiendishly difficult, I’ve never seen a CSS editor as comprehensive and comprehensible as a plain text-editor.
5. Single file: Unpacked trees should also be supported, for ease of development.
7. Named colours: I notice Ubuntu’s GTK+ theme configurator has buttons that allow you to configure the colours of various things; it seems to work by setting a “gtk-color-scheme” key in the theme file. If it were possible to hook into that, that would be pretty neat.
And here’s some more goals you might want to add to the list:
Resolution independence: v2 themes resize themselves to account for the size of the window title font, but extreme sizes in any non-trivial theme can look pretty silly. CSS is a good example, where every measurement is in terms of some particular unit which is defined relative to some external factor (such as the screen’s DPI, the size of the current font or the size of the window)
Extensibility: No matter what goes into a v3 theming spec, people will ask for more and different things in the future. If the v3 format clearly defines how to ignore unrecognised syntax, it may be possible to avoid having to bump the theme version for a long while. Again, the CSS design principle of “forward compatible parsing” is a useful model to follow, whether or not themes actually use CSS syntax:
http://www.w3.org/TR/CSS1/#forward-compatible-parsing
Declarative syntax: This is sort of implicitly covered by “2. Editing” and “11. Maximum power”, but I think it’s worth breaking out on its own. Theme syntax, where possible, should be expressed as declarative rules rather than as imperative algorithms. This should make editors at least possible, and makes it more difficult for theme-authors to do crazy things (although no doubt they’ll find a way).
Broken features are new features: There’s a number of v2 theme features that have never really worked correctly, and hence nobody really uses them (Thought: it would be useful to download a bunch of Metacity themes from gnome-look.org and do some bulk analysis of how frequently various features are used). Many of those broken features are actually pretty good ideas, though, so they should be dumped into the enhancement-request hopper along with all the other v3 theme features.
Second-system syndrome: There’s a lot of bug reports in bugzilla asking for all kinds of crazy features to be added to Metacity’s theme format (I’ve filed a few myself) and I know if I was responsible for organising a v3 format, the temptation to solve them all at once would be near unbearable. However, if the v3 format is just a reformulation of the working v2 features into a new, extensible format, all the shiny new features can be safely implemented later.