3

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

view full story
linux-howto

http://blogs.gnome.org – 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. Copyright © bitzcelt, cc-by-nc-nd. (Software)