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!
Yupp, that's a problem. But if only small parts were textured (i.e. the parts that require it), you could use a higher resolution and still save space and performance.
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.
XML is a great thing. It could lead to the end of diferences in the look between toolkis and desktops. Most people complain about choise when desktops are made to look the same way, but acctually, this is choise. Today you can't make a gnome app use the file open dialog from kde. If QT-Designet can load glade files, why trolltech and gtk team work on a kind of wrapper for the call of signals, so if the programer want, he choose to load a XML file that contains the visual choosing what widget will take it? This would be not mandatory of couse, if people don't want, just don't use this, and keep working qt and gtk apps as now. But it would be very cool if I could load gimp saying to it: use qt instead of gtk today, thanks. :)
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.
It uses scalable bitmaps, which is nice, but they can't go any bigger than 256x256
They're 128x128 actually.
Nae bother
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.
But that's the point, you don't get 4 or 5 icons. If you're lucky you'ill get one "Small" and one "Large" icon.
Plus inside applications you tend to only get one size of icon regardless of screen resolution.
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
...to have a really good SVG editing tool. GIMP 1.3.1 shows that some GNOME developers have put some serious thought into Bezier editing tools, but nothing that has been released as a standalone vector editing app. killustrator, sodipodi and similar apps just aren't ready for prime time. If you're willing to spend the time to use it, the GIMP is really about as powerful as photoshop. Unfortunately, there is nothing in the open source world which is anywhere near as close to Adobe Illustrator functionatlity.
Worth noting that NeXT had display Postscript robustly implemented and SGI's window manager also had scalable fonts, but neither of these OS or GUIs are around today. If there's a lesson to be learned here, it is that the UI isn't significantly improved by scalable vector graphics. SVG is an improvement but not one which will make any competitive difference. Fortunately or unfortunately, the 25 year history of user interface points us in a different direction.
http://tinyurl.com/4ny52
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
librsvg is faster *under certain circumstances*. Yes, if you create 2 milion vectors then it will be much slower. But most icons aren't made of 2 milion vectors, that's why they're faster.
I suggest you try out Sodipodi while it would be crazy to claim that it can do everything Illustrator can it is getting nice and usefull.
Yeah, I know, absolutely *nothing* can beat a blue "e" in intuitivity. I mean everybody just knows that "e" means "Web Browser", it's just the logical thing. Or a stylish "W" is a Word processor, what else can it be.
Sometimes I really start to think that the rumours about Microsoft paing people to post on various forum sites are true. Either that or some recently introduced and very common food preservative causes brain cancer or senility - or both.
Not really. A better fit would be Xr - librsvg does the rendering but Mozilla needs to do it itself for good integration. Using Xr however in place of libart would provide a better backend.
run your desktop at 2048x1536 and you'll get a harsh lesson in how poor the computing world deals with different resolutions.
.. Text Zoom] on mozilla & [View ... Text Size] on I.E.
If it wasn't for Mozilla's ability to have a minimum point size for fonts 75% of websites are too small to read (including my own).
Making a website that renders properly at all sorts of font sizes is a challenge.
A challenge made worse by I.E. & Mozilla's disagreement on what to change when you change the browser's font size. [View
I.e. doesn't change any font specified in pt, px em or en whereas moz changes soe of them but not others.
frikking n'mare
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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?
AFAIK it is more compliant at the moment because it supports more SVG features. But librsvg is just a static renderer, whereas KSVG aims to offer a complete DOM model to KJS, KDE's JavaScript engine. This allows Macromedia Flash-like interactive animations using SVG+JavaScript.
Crystal SVG was developed using Adobe Illustrator 9.
Although, being a windows user i could only view it using the Adobe SVG Viewer which only works in IE, any of you have an idea of how to make it work under opera7 drop me a line:)
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.
Except OSX uses bitmap images for their icons (TIF, PNG), not vector graphics (SVG).
Default icons are 128x128 pixels, but are usually displayed at 32x32. OSX just has a very good scaling algorithm.
Tuus crepidae innexilis sunt.
You are wrong on two counts: 1. There is a full syncronization between animation and graphics in Adobe SVG Viewer. Adobe audio element works just like SMIL audio element with all synchronization stuff available for it. 2. There is already an agreement that it should be perfectly legal to embed SMIL audio element in and SVG document and it should work just the way Adobe audio element does now.
You may want to check out Fresco, which would allow exactly that. In particular, the Fresco vs. X page might be interesting to you.
You know where you are? You're in the $PATH, baby. You're gonna get executed!