GNOME bug 107012 brings up the perennial question of SVG support in themes, otherwise known as Vectacity. We’ve already covered this in a few places, but I think it may be worth mentioning here the two main reasons SVG-based themes is a good thing (there may be any number of other reasons they’re a bad thing, as well):
- SVG is now a clear standard for vector graphics. So theme artists will be able to reuse their existing knowledge about SVG when coming to design Metacity themes.
- It means we can remove large amounts of code from Metacity and use whatever SVG library we end up depending on instead. (There is a heavy presumption that this library will be GNOME’s own librsvg.) Having less code around is generally a positive thing.
However, stretching SVG to meet our needs, or indeed stretching librsvg to meet our needs, rather negates the second benefit: it’s possible that including CSS will let us do what we need, but it’s also possible that librsvg is not clever enough to let this happen without so much coaxing on our side that we may as well have written an entire SVG library of our own, which is something we’d like to avoid.
If Vectacity ever becomes a reality, it certainly needs to be possible to convert a v1 or v2 theme to Vectacity automatically. This is partly for the theme artists’ benefit, but also because it means if a Vectacity-enabled Metacity finds itself having to load a v1 or v2 theme, it can do the conversion by spawning a separate program rather than having to keep the legacy code for reading v1 and v2 themes lying around, which again negates the second benefit.
Forthcoming versions of SVG are specifically considering use by window managers, but we may have to wait a while for them to get into a usable format. It may be best to WONTFIX this one, at least until v4. On the other hand, the two benefits given are indeed important benefits, and I’d like to see it happen sooner.
Photo © freebird (bobinson|ബോബിന്സണ്), cc-by-nc-sa.