After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 107012 - SVG theme support
SVG theme support
Product: metacity
Classification: Other
Component: general
Other Linux
: Normal enhancement
: future
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks: 102547
Reported: 2003-02-25 08:46 UTC by Havoc Pennington
Modified: 2017-03-03 14:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

Demonstration that SVG support is already working (3.58 KB, application/x-bzip)
2006-03-23 00:38 UTC, Thomas Thurman

Description Havoc Pennington 2003-02-25 08:46:23 UTC
Will probably need an optional librsvg dependency to do this sanely, so 
it's fast enough etc.
Comment 1 Sebastien Delestaing 2004-01-04 20:25:19 UTC
Could you elaborate ? Why is it optional, is there another way of
loading SVG ?
Comment 2 Rob Adams 2004-01-04 20:57:09 UTC
compile-time option to disable SVG support, like startup notification,
xinerama, randr, etc.
Comment 3 Havoc Pennington 2004-01-04 21:31:48 UTC
I think the main point about the librsvg dependency is to do it that
way rather than via gdk-pixbuf. The problem with gdk-pixbuf is that
we'd need to reload the SVG from disk each time we scale it, unless
gdk-pixbuf has been enhanced to avoid that. With librsvg we'd instead
keep the svg in memory and just re-render it as you resize the window.

Another library out there is Cairo + xsvg, I think, though librsvg is
probably a better idea at the moment due to maturity.
Comment 4 James Cape 2004-01-28 23:33:47 UTC
You can use GdkPixbufLoader to load the svg images to size based on
in-memory data (so metacity would cache the file contents and pass
those to the pixbuf loader).

I'm not sure how librsvg handles caching, or if that would be any
faster, but the above method would eliminate at least the disk access.
Comment 5 Thomas Thurman 2006-03-12 19:26:30 UTC
It occurs to me that if we had good, fast support for SVG in themes using one of the SVG libraries, we might not need our own XML drawing format like <rectangle> and <line> and so on (except for backwards compatibility). That would give us lots of goodies, too (like fancy gradients, say, solving bug 321278 straight off).
Comment 6 Thomas Thurman 2006-03-23 00:37:07 UTC
I'd just like to say that GTK is the cat's pyjamas. I sat down this evening to start figuring out how SVG theme support would work, and found the API looks just the same as support for raster images. In other words, we already do support SVG. I'll attach a silly little theme I just made that demonstrates this.

This also means that we get to close bug 321278 and possibly others for free. Woohoo.
Comment 7 Thomas Thurman 2006-03-23 00:38:41 UTC
Created attachment 61813 [details]
Demonstration that SVG support is already working

This theme sets the titlebar to an SVG file containing a diagonal gradient fill on the left and a radial fill on the right. It looks pretty ridiculous, but it shows the point.
Comment 8 Thomas Thurman 2006-03-23 00:43:11 UTC
If anyone else can reproduce my results, I think we can mark this FIXED now.

We could make some really wacky themes with this. It should be fun. I think it means that there's no longer any need to create any new drawing primitives. You could even get away with deprecating everything other than <image/>, I suppose.
Comment 9 Havoc Pennington 2006-03-24 03:04:16 UTC
If you mean loading svg with gdk-pixbuf, see the earlier comment on this bug for the problem there (I think?). If you load svg "natively"/as-vector then you're right, additional primitives would not necessarily be needed... although, note that if the theme were just a big svg image you wouldn't be able to properly line up elements with the buttons, adjust for various font sizes, etc. - so it will remain important to have the "layout" handled in the metacity format, or something.

When messing with any theme feature, be sure to use metacity-theme-viewer to look at all the window types and the button combinatorics and be sure the theme feature can support the diversity of cases.

Another note on this bug is that Cairo has become the clear choice in the modern world, right...