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.
So many confusing ideas here!
If the theme file is SVG, why would images be in XPM format rather than SVG? Besides which, XPM doesn’t support alpha-channel images, which are rather useful for theming against arbitrary background colors.
Embedding image files sounds like it would be more annoying than useful, because every time you need to edit an image you need to export it from the theme, edit it, then rebuild the theme file including the new data.
If creating a single-file theme format is important, it’d probably be easier and more popular to re-use an existing archive format like .zip or .tar (potentially renamed – Java’s .jar, Quake 3’s .pk3, Winamp’s .wsz and OpenDoc’s .odt are all just renamed .zip files) rather than inventing yet another bundling system – besides, Metacity themes are already distributed as tarballs and can be installed by dropping them onto the Appearance Preferences control-panel, so it’s hard to make distribution much easier.
Overall, I’m not entirely fussed about SVG themes – as far as I can see the primary advantages is being able to re-use editors like Inkscape. If one then has to open up the theme-file by hand and annotate the machine-generated SVG with theme-layout hints and re-annotate every time something is modified and doesn’t quite round-trip successfully, I wouldn’t enjoy it at all.
Here’s some less radical improvements that I think would provide big advantages (no bugs filed, but I can do that if it would be appreciated):
– Something like cpp’s #include directive. Often on gnome-look.org you’ll see themes that actually contain a bundle of related themes, such as every possible combination of menu-button-has-icon-or-arrow, square-or-round-corners, centred-or-left-aligned-title. One basic design produces eight separate theme files! If you could have some common files for the basic set of frame_geometry and draw_ops records included into every theme, that would be much easier.
– Another cause of multiple theme-files-per-download is configuration – some themes that aren’t based off the GTK+ theme colours provide a collection of individual theme files that only customise the colours used. If there were standard schema attributes for the constant element such as type=”color” and description=”Color of inactive titlebars”, it would be possible to add automated GUI configuration of things that currently require XML-fu to edit.
Why not just use Seed for scripting (the WebKit JS engine + GObject introspection)? It is likely about to be adopted by Epiphany as the extension engine. Having a sensible default scripting language that relies on GObject introspection would allow themes to be scripted in any other language that supports GObject introspection too.
Oh, I forgot to mention – I’m not totally anti-SVG, but it would be nice if one could render SVG images at the target resolution rather than having them rendered to bitmaps with librsvg and *then* scaled to suit. Bug 561896 is a long and rambly whine about trying to use SVG with Metacity themes.
I think I probably shouldn’t post at this time of night :)
@Screwtape:
If the theme file is SVG, why would images be in XPM format rather than SVG?
Because of the requirement that all existing themes be representable in v3 format (just as any v1 theme can be represented in v2 format). Some themes (Crux is an example) use images already, and though it’s deprecated it has to be allowable in v3 as well.
I do like the idea of reusing zip. I have actually been considering that as an output format for the v1/v2 theme editor.
Includes: yes, good idea. It would also make it more possible to have titlebar buttons that weren’t contained in every single theme.
The automated editability thing is a good idea and one I hadn’t considered. Thanks.
(Do also note that this is all thought-experiment, and we may not actually ever do the switch to SVG.)
@Luke:
The point is not to allow arbitrary scripting as JavaScript would allow, but merely and only to allow an expression language to describe how theme layouts are rescaled on the fly.
Here are some ideas about a way to define themes:
If you are going the SVG way, why not separating concerns: visual elements and layout hints.
That way, there should be at least two XML files bundled in one archive file (zip or whatever), plus optional bitmap files if needed.
One of the two XML files should be a standard SVG file that defines all visual elements; and as SVG may include bitmaps, you will be able to define an image as a visual element.
The other XML file should be some kind of configuration file to give some layout hints. Like in which text element put the window title, what elements serves as borders, …
This configuration file should just uses XML IDs to refer to visual elements (those ID are customizable in inkscape).
Also, by defining some standard XML ID, the configuration file can be simplified if the theme author uses those standard ID in his SVG file.
@Thomas:
I’m sure a lot more themes would use PNG images than XPM images; if you really need an ascii-formatted format perhaps one of the netpbm format suite would suit.
Also, I was blindly assuming that SVG (like other vector formats including PostScript, Corel Draw, and WMF) was capable of encapsulating bitmap data along with vector data. It seems that while Inkscape can save vector and bitmap data into the same file, the file in question is actually… a .zip containing the base .svg and all the other components.
@Screwtape:
Oh, I’m sure nobody really uses XPM images, but I mention XPM because it has roughly equivalent power to PNG (it’s lossless), it’s text-based, and the GNOME libraries can read it out of the box. I’m imagining that some kind of theme editor like Opacity would covert the files on the fly.
This is all assuming we’re doing the SVG thing anyway, of course… I think we’ll go with the zipfile idea for current versions of the format, anyway.
Well, except that (as I mentioned), XPM doesn’t support alpha-channels in images while PNG does. I suggested a netpbm format because they also are ASCII-based formats, but designed to be a superset of every bitmap graphics format.