Themes roundup

Here are four pieces of news from the world of theming.

1. Human may be replaced. We don’t usually cover news about specific themes here (although perhaps we should) but it’s worth noting that Ubuntu’s default theme, Human, although very beautiful, is a little long in the tooth.  There has been a proposal to replace it in 10.4 Lucid Lynx with a new, similar theme called Homosapien.  (Your chronicler notes that the human species is homo sapiens sapiens, not *homo sapien, and wonders whether it is too late to change the name.)
2. Universal theme format. At present, there are scores of different formats for theming user interfaces, some of which are often packaged together to be complementary or alternatives. There are also various metatheme formats for packaging several disparate types of theme together, but they are specific to a particular desktop. David D Lowe has proposed a “universal theme format”, which is a container for various types of themes, to be considered as a freedesktop.org standard. Time will tell whether it’s adopted, but for the moment, gentle reader, you can find out the details in this PDF (there is no HTML version, unfortunately).
3. The state of Cowbell. Speaking of universal theme formats, Cowbell is an attempt to allow theming using CSS rather than Metacity’s own rather recondite theme format, which may hopefully one day be picked up by other window managers.  More work has been done on the cowbell branch than has seen the light of day, but it has proved difficult to merge the existing content with the master branch; furthermore, we should probably be looking at keeping the CSS theme code separate in a library so that other window managers can use it as well.  So the branch has been quiet recently.  There are plans to forge ahead with what we have, however, and to integrate the results of the detailed discussion on the subject at the end of last year.
4. Cowbell and its dependencies. There are several ways in which the current libccss-based implementation falls short of what we need, at least last time we checked. Any or all of these apparent problems may be mistaken, but:
   • Several of the CSS3 selectors which would be really useful weren’t implemented, even things like sibling selectors.
   • There’s also a lot of flexibility we don’t need, since our “documents” are of a fixed form.
   • There’s apparently no way to refer to a window’s icon other than by saving it as a bitmap and reloading it.
   • Some of the extensions we’d need to have equivalent power to the v2 theme system, such as -cowbell-replace-color, look like they’d be a nightmare to implement for similar reasons.
   • We can’t easily implement the requirement that it should be possible to load images from a tarball, for similar reasons.
   • We can’t easily add new colours, which we’d need to to implement system colours (which may be deprecated but suit our purpose very well), or any similar way of getting at the GTK colours.

   We could work around these, but it’s far better to make the theme format usable by humans than to tie ourselves in knots to get around infelicities in the software.  And we always have the option of adapting libccss to our needs.  But a lot of what we need to do is specific to our own case, and if this results in tying the library in knots it may become better to write a stripped-down in-house CSS parser that does what we want and is, as they used to say in Cambridge in the old days, BALGE: by and large good enough.

Gentle reader, we love your letters.  Let us know your news, whether or not it’s about themes.

Photo © camera_obscura, cc-by-nc.