…for the adult in you

Further to our previous discussion of CSS, Thomas spent a few hours on sketching out a possible design for a CSS-based theme format, and on representing Daniel Borgmann’s Human theme using it. This is an experiment, all very blue-sky and unofficial, and is quite likely never to lead anywhere.

The first question to resolve is how the interplay of element names, classes, and identifiers applies to us. For example, when styling the close button, is it:

• a button with id=”close”, or
• a box with class=”button” and id=”close”, or
• a close with no class or id attributes?

For simplicity, we went with the last option.  We represent the decorations of a window frame using a set of unique element names arranged into a particular hierarchy.  Almost every element is a simple box; the exception is title which is textual.

We use libccss to parse the theme and also to apply certain of the box styles; this means that this experiment is drawn using Cairo.  (It would have been possible but more complicated to use nbtk for styling, which would have meant this experiment used Clutter.  This is more probably what a final working result would be like.  An attempt was made to use nbtk but some of the more complicated styling options appeared to be currently unsupported.)

libccss supported background images and reasonably complex border drawing.  There were two things we needed which it did not (yet) support, so we had to kludge those in:

• text styling, for the title; we only bothered to implement justification.  Our approach here is to use a simple text label for the title and to style it, rather than using explicit vector graphics as in v2.  Effects like Human’s shadowing would be implemented by something like CSS3’s text-shadow.  More complicated arrangements like Atlanta’s centred icons would be impossible.
• the complete CSS box model; only borders were supported.  We made a half-hearted attempt to support margin, and did not even touch padding.  However, in so doing, we made…

A useful discovery: In doing this it became clear that there are two possible ways for a file format to describe vector graphics.  Either the position of everything can be represented using arithmetic expressions, which is how the current Metacity theme format works, or it can use a hierarchical box model, as HTML and CSS do.  One of our stated aims for v3 is ease of editing, and the box model appears to be a better fit for humans to understand in a drag-and-drop editor (as seen, for example, in Inkscape).  Therefore, if we do not adopt SVG or CSS for v3, it may be worthwhile to look into box-based layout models even in a custom format.

Here’s one draft of the CSS for Human, and the results of processing it with this hacky and experimental code are shown on the right (with the real thing around it for comparison).

Problems and challenges:

• New properties. We are certainly going to need to invent properties which are unheard of in real CSS. (For example, corners will need to indicate the degree of rounding.) These properties should probably be marked in some way. Mozilla marks its new properties with a leading -moz; perhaps we should do something similar.
• Dublin Core metadata. This could be implemented using custom properties on the toplevel “theme” element, representing the author, licence, and so on.
• Named colours (especially those which refer to the GTK theme).  libccss does not allow new colour names to be defined; perhaps we should ask for this.  On the other hand, it does allow new callback functions to be created, so that you can write color: gtk("bg-selected") or something.  This allows us to get the same effect at least within the CSS.  However…
• Pixmaps.  This system is well-suited to defining pixmap themes, which are at least fast, easy to understand, and simple to manipulate.  However, they are generally discouraged because they scale badly and don’t recolour well when the GTK colours change.  There are two possible workarounds:
  • Introduce custom properties to scale and colourise the pixmaps as appropriate.  v2 is already capable of pixmap colourisation (it’s used quite heavily in Crux, since that is a pixmap theme, but rarely elsewhere).
  • Use SVG images instead.  This immediately brings up the problem of how to style these images: we could of course use this very CSS to style them, but then our custom callback functions to get GTK colours would still need to be honoured somehow.

Conclusions:

• CSS has possibilities as a window border format: it is a standard and well-understood format and there are plenty of tools around to edit and parse it. However, it is certainly not as powerful as v2 and probably cannot be.  That may not be a problem, as we said before.
• As somebody mentioned earlier, research is needed to discover which features of v2 are commonly used, and therefore necessary in any possible v3.  We need to make a big collection of themes and score each feature with how heavily it is used.
• Box-based layout is simpler for humans to edit (and perhaps to understand in general) than expression-based layout.

Photo © rogdorf, cc-by-nc-sa.