Several ideas have come up recently about extensions to the theme format. Here are some rather disjointed notes about the problems we face here. I apologise for their fragmentary nature.
According to policy, incompatible changes must be made all at once with a new version of the theme format, to preserve backward compatibility. (This has only happened once so far, so the only versions of the theme format to exist are v1 and v2.)
One feature I’d like in a new theme format is to have everything in the same file. At present we have almost everything together except the pixmaps. I’d like to put them in the same file; rather than using base64, we should use xpm for this, which gdk supports out of the box. That way, you can have just one single file to download. Also for ease of sharing, it should have the theme name in the filename this time, rather than the directory name.
As to the format of the new files, there’s a strong suggestion around that they should be SVG. Such a format could either be designed from the ground up or be an evolution of the current system. However, I believe that what is needed is a clear upgrade path, and so we need an evolutionary approach. If we can build a conversion utility to convert v1 and v2 themes into v3 themes, then not only will people be able to work with all their existing themes immediately, but we can support only v3 in Metacity itself and call the conversion utility when a theme is encountered which only supports v1 or v2.
One problem with both the evolutionary and revolutionary approaches is that there are ideas in Metacity themes which cannot be expressed in SVG: for example, some themes place a graphic to the left or right of a piece of text of unknown length. I have spoken informally to a member of the SVG Working Group who has confirmed that this is not possible in current pure SVG designs. However, it is possible with scripting. So we can consider a simple refinement of our existing coordinate-expression system as a form of SVG scripting system, where we set the dimensions and positions of elements with respect to other elements.
Something like this could be achieved using librsvg by building a text buffer containing the XML with sufficient whitespace to the left of every decimal. As our homegrown scripting language was parsed we’d build up a set of pairs of (char*, expression) and every time a frame was drawn we’d simply write the new value into the buffer. It would obviously be simpler if we could modify the parsed form of the SVG inside librsvg, but I don’t believe it allows that. More importantly, we need to be able to find the widths and heights of various elements, especially the title, in order to position other elements, and I don’t believe librsvg allows us to read its parsed form either. (Do you know otherwise?) If not, where can we go?
Of course we could possibly keep doing it in house as we do now, but use an SVG-like syntax instead. Effectively we’d be writing our own SVG library. This is not exactly a cause for rejoicing.
Photo © James Jordan, cc-by-nd.
