Slashdot Mirror
Major Step Forward For SVG in the Desktop
Ur@eus writes "SVG the w3c format for Scalable Vector Graphics is seen as many as the future of desktop icons as it allows for scaling icons etc. without loss of quality. Dominic Lachowicz has been working hard on fixing bugs in librsvg over the last few days. The result is that librsvg now renders all available SVG icons perfectly.
Not only do it render them, but it renders them faster than libpng renders the same images in png format.
Together with the gdkpixbuf plugin librsvg offer it means GNOME 2.2 will be able to use SVG images not only for icons or desktop backgrounds, but also for the GUI widgets themselves and the graphics of the window manager.
Dom's announcement can be found on the librsvg mailinglist. The librsvg site also offer a GNOME 2.2 metatheme using mostly SVG icons including a nice screenshot."
Why not? The scalable aspect means you would only have to supply one icon file for different resolutions. You could have applications where the proportions where exactly the same regardless of if the resolution was 800x600 or 1280x1024.
It would still be an improvement though.
My UID is prime!
This functionality is already in Nautilus. They're called emblems. You have read-only emblems, Music Folder emblems, etc. It supports both PNG and SVG emblems.
Maybe Konq has this too, but i haven't used it in i-dont-know-how-many years, so i dunno if it does.
Bzzt, wrong. MacOS does not have any SVG or vector icon capability. It uses scalable bitmaps, which is nice, but they can't go any bigger than 256x256. That means, no resolution independance for you - ie in a true res independant desktop doubling the resolution just makes things sharper, as opposed to smaller.
Note that this implementation probably won't do MacOS style fast zooming (not that it's all that useful anyway). For that I think we have to wait for XSVG, which actually integrates with the X server and can offer hardware accelerated SVG rendering (note that librsvg is faster than libpng in some cases).
Having the same capability with something as lowly as desktop icon is amazing! The next logical step is UI widgets and other elements of the desktop.
GTK already supports SVG themes, but I think a bit more work is required to make them really usable and realistic.
KDE in it's CVS version for KDE 3.0 was able to render .svgz (gzip-compressed svg's) in realtime as well (to be more exact: all crystal icons that existed up to that time) the feature has been disabled mostly due to maintainance issues and due to the fact that it was meant to be used for the default icon set. As the stuff hadn't been tested thoroughly until then and as it was only finished right for the last beta we postponed it for 3.2. Another reason was that the icon set wasn't in a final state.
So although almost all icons in kdelibs are rendered using svgz files you have to invoke kde2png explicetly to create larger pixmaps from svgz's.
It is not only what you need on the desktop but also what people want. On a similar note, who *needs* flash on a webpage, or even GUI interfaces?
Personally I wouldn't mind seeing a truly open specification as the standard for scalable vector graphics, and this seems to be *the* candidate for it. From the w3c webpage on SVG:
SVG is a language for describing two-dimensional graphics in XML. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. Text can be in any XML namespace suitable to the appplication, which enhances searchability and accessibility of the SVG graphics. The feature set includes nested transformations, clipping paths, alpha masks, filter effects, template objects and extensibility.
SVG drawings can be dynamic and interactive. The Document Object Model (DOM) for SVG, which includes the full XML DOM, allows for straightforward and efficient vector graphics animation via scripting. A rich set of event handlers such as onmouseover and onclick can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on SVG elements and other XML elements from different namespaces simultaneously within the same Web page.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
GNOME's been doing SVG icons for a long time -- this is an evolutionary improvement. This is another area in which it took quite a while for KDE to catch up, not GNOME.
I wonder if KDE is using libsrvg to render the icons, as opposed to some Qt stuff. If so, both environments will immediately benefit.
May we never see th
Mozilla has an active SVG project. The renderer is not yet included in the main build, mostly for licensing reasons. But you can build it in yourself and there is someone that maintains a Windows build. See the link for more info.
- -
Are you an SF Fan? Are you a Tru-Fan?
The reason you get more room isn't because you've changed resolutions, it's because at higher resolutions, your display elements (GUI, fonts, etc.) shrink in size, thus making room for more stuff.
In a vector world, if you wanted more space on your desktop, you wouldn't change resolutions (ideally, you'd already be at the highest resolution your hardware supported), you would explicitly shrink your display elements (GUI, fonts, etc.) so they consumed less space. (Or get another monitor.)
And who knows, once everything's done with vectors, your GUI might grow and shrink the size of active/active windows ("zoom") to give you all the room you need. MacOS X already does something similar with its task bar.