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."
Now, what is the problem with icons today??? They're ICONS. It's not like they're actual programs that matter! They're ICONS! C'mon!
This will pave the way for bigger and better OSX clones! Honestly, do we really need SVG icons on the desktop ? All i do is click my icons, i don't need them to enlarge to 200% when I mouse over them or shrink to nothing when I click them. I understand the need for eye candy, which is cool, but SVG icons aren't on the top of my list. Eye candy ? www.sh0t.com/gnome.jpg Anyhow, it's an advancement nonetheless
Great work librsvg team!!! I look forward to the day when there is no more Flash because SVG is so well supported. SVG: XML based, open standard, w3c backed, blah, blah. I love it! SVG is the ISH!
What about replacing flash animations in web sites with something really standard?
However the entire quartz graphics subsystem supports all sorts of vector based operations and translations. Its a lot of fun to play with. Look at all of the shrunken window effects.
-- Oh Well
Suppose you want your desktop to look in some specific way, without worrying about resolution. If you have a big monitor and/or an extra-high resolution maybe your standard sized icons will look very small, and, in the other hand, they could look pixelated if they are "standard" icons magnified.
With this you have icons that looks good and in the same aparent size in any resolution
And I want mine to be the same size regardless of my screen resolution. So I'll be happy and you can still use bitmaps.
Bloody hell - there is "the glass is half empty" and then there's "I hate glasses and really don't see what use they are to me or the rest of the planet".
Carpe Daemon
First, Gnome have SVG in real time, you can choose a .svg as icon file. KDE should had this for 3.1, but as their lib wasn't very good, they now target it for 3.2.
Second, they aren't saying gnome just got it, it's been there since 2.0, it's just better now.
PS: I'm a KDE user, but I'm fair, SVG in KDE still sucks.
BeOS did something close to this. Although vector-based icons are more suited to this.
I could start ftp download and then just keep an eye on the file's icon in the Tracker for progress... Very useful.
J.
You seem to be under the impression that the OSX-icons are SVG. This is not true. They are just resource forks containing several different sized icons so that they seem to scale "magically".
They might be drawn with Vector based drawing, but they ARE converted before used as icons. KDE does the same thing. The excellent Crystal Icons are SVG-based, but they are converted to PNG for KDE, hence the incorrect assumption that KDE supports SVG. KDE is supposed to get SVG-support in KDE 3.2.
I am not your aunt Tilly people!
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Covers everything at this time. Max resolutions have gone up year on year, but most people don't use the full capabilities of their card/monitor because the screen elements become too small. So having a resolution independant desktop would be a good way of solving that issue (though obviously you still get these issues with the web).
It's a step towards what we should have had long ago: a desktop where you don't need to know what resolution it's running at, things are just scaled to the correct size. It's crazy that changing to a higher resolution display (eg from 800x600 to 1024x768 on the same monitor) makes all the window decorations and icons smaller. Fonts are supposed to remain the same size, but often they don't.
Obviously for really low resolutions the scale might need to be increased to keep things readable, but a 3200x2400 desktop should look identical to 800x600 except for increased sharpness and detail. (You can still choose really tiny icons if you want them, of course.)
-- Ed Avis ed@membled.com
amen to that
I'm running 2048x1536 on a 22" & I'm very happy that for the first time in my computing career instead of using the space to display somewhere near a useful amount of workspace I can actually keep the workspace the same size and turn up the font size.
Running a term where the chars are 1cm high but I can still get 100+ columns is a godsend.
Big fonts rule and all the better that I have a dual head system and I dont have to squint at IRC to read the text. I can have it at 22pt and read it from anywhere in the room.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I seem to be alone here as the only person who actually thinks this is a fantastic idea...
:)
The whole point about SVG is that they will render nicely whatever the screen size... This isn't only relevant for big screens. This means that my iPAQ's tiny little 320x240 screen won't have to be eaten up by huge bitmap icons.
The SVG stuff should tie in beautifully with the sub-pixel rendering in X.
Congratulations to the author(s) for their great work..
Looks like linux just gained yet another feature that windows is lacking.
Well Done
Thing is, frequently you want a loss of quality when you scale an icon. Who cares about all the pretty brown crinkles in the Gnome foot icon when it's at 12 x 12? They won't read like crinkles, they'll read like a muddy mess. A simple outline is probably best at that size.
Now, a format that defines a priority heirarchy among the vectors on the image, and a scaling factor at which size various low priorities of vectors are not rendered... That might be very, very useful for icons.
I'm surprised no one has mentioned a key benefit of SVG desktops: session migration.
Ever notice how primitive systems like WinXX have some serious layout problems with a network login user moving from their "usual" 1280x1024 desktop to a temporary workstation that is set for 800x600? The icons get repositioned to be visible, destroying any custom layout the user had -- and that is assuming they were all in the upper/left of the screen. Heaven forbid the user had bothered with placing any of them on the right hand edge of their screen!
Deploying a "thin client" desktop is even worse, as you need to be able to scale the virtual desktop to fit the physical screen being used at the time. As PCs become more innocuous (think payphones), it will be natural for people to expect to have an identical session no matter what they are using to link with their home server session.
Sure we're still 5-10 years from the point where those facilities are "needed", but without a solid foundation in place we can't even think about deploying those kind of systems efficiently.
I do not fail; I succeed at finding out what does not work.
For a program I'm writing, I use Ghostscript to render some postscript in one of my windows, but I wouldn't dream of using it to render my GUI widgets. :-)
The ocean parts and the meteors come down
Laid out in amber, baby.
Note that this implementation probably won't do MacOS style fast zooming (not that it's all that useful anyway).
I think zooming may play a much more important role in future GUIs. While the Dock's little parlour trick has limited functionality - apart from being a nifty demo - in its current form, I can see all sorts of situations where you could impart a huge amount of information through a 'zoom-up'.
For example, those icon badges mentioned before. I find myself wishing for both more informational icons, and a keyboard-activated zoom focus. The Mail icon shows you how much mail you've got, that's nice... but I want more info. It would be great to mouse over the icon and have the connections/progress listed. Or, roll over the clock and have a calendar zoom out at you like a springloaded folder... putting itself away when you roll away. This gives you a really high amount of information density in a small amount of screen space. The SVG icons are great, the only problem I can see with them is for photographic material. Postscript-type files are fantastic and small for line art/gradients, but if you tried to vectorize a photo of Linus' head it would be a very large icon data-wise... much larger than a standard bitmap would be. I suspect this is why the OS X team went with the vector-transformed large bitmaps (someone else pointed out - or was it you RealMike? - that 256x256 icons are good for now, I'd respectfully point out that the 32x32 icons are still appropriate for most modern resolutions... 256 pixels will carry us well into the next 8 years barring otherworldly jumps in display resolution.)
If Jesus wants me it knows where to find me.
I don't want my icons to be huge!
You just don't get it. Size should be a property of the rendering, not of the icon. SVG allows this, bitmaps don't.
You can make an icon out of any SVG file by telling your desktop to render it. Not only that, but it looks good whether you are on 1920*1200 or 640*480.
In a perfect world, you wouldn't have to increase the font size when your resolution grows. Instead, you'd tell the computer about the resolution and it would adjust the font rendering accordingly. Remember that pt is an absolute measure (1/72 inch), as in "Computer, make that font 22pt tall and I don't care how many pixels you will use".
It has been a problem for a long time that fonts would scale up with increased rendering resolution, but icons wouldn't, destroying the visual composition. SVG can definitely make that better.
You would think with everyones rant that this was really new technology. Vector image formats are not new.
In fact there is an age old debate, of bitmap (pixel-based) and vector. Pixel based has it's drawbacks of not being scalable, and being bigger in file size. Vector, on the otherhand is scaleable and smaller in file size.
We should, however, remember the big tradeoff for vector, and that is what is gained in scalable quality is lost in rendering processor time. I could imagine some extremely complex icons being created really grinding GNOME on the rendering. Additionally, add XML as the native format, while useful in many applications, processing/parsing XML is not the ideal...
I'll be impressed when I see it and run it on my old beater box that I currently can run GNOME on...
Although, I guess if it really " renders them faster than libpng renders the same images in png format." maybe it'll be the holy gail afterall.
...is going to be big enough for a while.
What you're basically advocating is changing the "standard icon size" every few years, as display resolutions go up. You also suggest that for print, vector graphics are better. What happens when display resolutions catch up to today's printer resolutions? Will you only advocate a switch to vector graphics when that day arrives? Or by that time will we be using 1024x1024 icons?
I used to fall into this trap from time to time myself. See, whenever somebody on Slashdot says "standard," they mean one of very specific thing: a specification entangled in draconian license terms that make commercial use impossible. No standard created and promoted by a company can be a "standard" in the Slashdot sense. So Flash is not a "standard" for the same reason that the QuickTime file format is not a "standard:" because, despite the fact that they are fully documented and readily available for any to use, both of those formats were developed by companies. And companies, of course, are inherently bad, according to Slashdot collectivist groupthink.
It's an easy mistake to make, misunderstanding the common usage of the word "standard" on Slashdot. The same problem arises with the word "open," and don't even get me started on the word "free."
I write in my journal