Major Step Forward For SVG in the Desktop 363
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."
odd (Score:2, Insightful)
Re:odd (Score:5, Insightful)
Re:odd (Score:2, Insightful)
On the other hand, the SVG would have to be yet another library to have installed on your system, with all the problems associated with having yet another library
Re:odd (Score:5, Interesting)
SGI's Indigo Magic desktop has done scalable vector icons forever, and its beautiful. Not only can you set the standard icon size but they put a handy thumbwheel in the "explorer" window to let you zoom in and out of your files.
Don't knock it till you've tried it. :)
Re:odd (Score:5, Insightful)
Just more OSX themes. (Score:2, Insightful)
Re:Just more OSX themes. (Score:5, Insightful)
Also, the more it will be used, the faster it will hopefully become available in browsers out of the box so we can finally ditch flash...
Re:Just more OSX themes. (Score:4, Funny)
cat pr0n.gz | gunzip | svgviewer
"mmmmm, scalable porn...."
Re:Just more OSX themes. (Score:3, Informative)
Default icons are 128x128 pixels, but are usually displayed at 32x32. OSX just has a very good scaling algorithm.
Re:Just more OSX themes. (Score:2)
I can see a need for SVG, but not for SVG icons.
Re:Just more OSX themes. (Score:3, Insightful)
This is a great thing!!! (Score:5, Insightful)
Re:This is a great thing!!! (Score:3, Interesting)
You may be waiting for something else then. While SVG supports animated vector graphics, there isn't anything in the spec for syncing audio to the graphics. I believe Adobe's plug-in has extensions for adding a sound clip, but still no way of syncing this up with what's happening in the animation.
Sorry, but you are wrong (Score:3, Informative)
Stateful Icons? (Score:5, Interesting)
Even more so, using XML and SVG, it would be very easy to create additional icons without a lot of programming behind it. You may need to a SAX reader to take the stateful information into some form, but after that, it's just XSLT transformations into SVG, and voila, you have an easy way to make cool meters/icons.
Re: Stateful Icons? (Score:5, Informative)
Maybe Konq has this too, but i haven't used it in i-dont-know-how-many years, so i dunno if it does.
Re: Stateful Icons? (Score:4, Interesting)
Personally I suspect there's not a great deal of point in making icons vector: 128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes) seems to cover pretty much everything. At least for the tasks icons are typically used for. Anything larger than 128x128 is turning into a picture rather than an icon (yeah, you could use the same format for both, but why bother - 99% of the time an icon is just blitted to the screen or used for hit testing, both of which an 32-bit pixmap is ideal for).
Re: Stateful Icons? (Score:5, Insightful)
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).
Re: Stateful Icons? (Score:2)
So is the scaling algorithm more or less expensive than the SVG renderer? What about CPUs with no hardware floating point (goes for both SVG and bitmap)? What about scaling to print?
Re: Stateful Icons? (Score:3, Insightful)
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?
Re: Stateful Icons? (Score:5, Interesting)
People complain that GNOME and KDE are memory-hogs and slow, but realistically, most of the overhead is in things like pixmap storage (not going to go away with SVG or PNG, since both have to be rendered down to an X Pixmap). Beyond that, you have to start hacking away at every bit of performance and memory use you can find. This is one such.
I assume that KDE already has or is working on SVG too. It's a logical step. Heck, they *could* just use this lib if they don't already have one.
Re: Stateful Icons? (Score:5, Insightful)
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.)
Re: Stateful Icons? (Score:3, Interesting)
Re: Stateful Icons? (Score:5, Informative)
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.
Re: Stateful Icons? (Score:3, Interesting)
They're called emblems.
While emblems affixed to icons are nice, that's not what the parent post was talking about.
With stateful alternative artwork, a folder icon could appear open or closed or locked or zipped. A trashcan could appear lidded, unlidded, bulging or empty. Emblems don't do that.
With stateful procedural rendering, a folder icon could appear tinted or shadowed or translucent or scaled to highlight different ownership or age or some other user-defined categorical criteria. Emblems don't do that.
With stateful procedural animation, a folder icon could glint, shudder, bulge, wave or otherwise animate when the mouse floats over the icon, or when objects change status in some way.
Further, emblems should be able to do all of these things independently from the icons themselves: the icon itself may glint and bulge while the emblems blush or twist.
Sure, bad themes would be a distraction, but good themes could provide a lot richer interface to a very dense data space. This is true of Flash, of Skinnable applications, and of GUIs in general.
Re:Stateful Icons? (Score:3, Insightful)
I could start ftp download and then just keep an eye on the file's icon in the Tracker for progress... Very useful.
J.
great lib name (Score:5, Funny)
That looks like someone headbutted the keyboard...
Re:great lib name (Score:2)
Re:great lib name (Score:5, Funny)
That looks like someone headbutted the keyboard..."
He had his cat name it.
Once again... /.'ers rally against the cause... (Score:5, Interesting)
One of the big reasons I like OSX (and I do not own a Mac, FYI) are the scalable vector icons. We've had vector based fonts for quite some time and you'd be hard pressed to find anybody out there who would rally against the scourge of vector fonts. For crying out loud... I believe it's KDE that has font anti-aliasing. I am sure we all have seen WindowsXP's "clear type" font smoothing. Anti-aliased fonts work pretty damn well and look absolutely super!
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.
As more and more LCD and other high-quality displays become the norm (many laptops feature 1400x1050 or 1600x1200 displays these days), not only are scalable fonts and UI widgets neccessary, there is an inherent human aspect to having a computer interface with the same perceived clarity of the real world.
I think this is a fantastic implementation of vector graphics. I only hope that we can soon have entire UI's based around scalable graphics as well.
Re:Once again... /.'ers rally against the cause... (Score:5, Informative)
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.
Re:Once again... /.'ers rally against the cause... (Score:2, Informative)
They're 128x128 actually.
Re:Once again... /.'ers rally against the cause... (Score:2, Funny)
And I've been trying like mad to get them to change this. All I want is a single 1024x768 icon for Emacs on my desktop.
Re:Once again... /.'ers rally against the cause... (Score:3, Insightful)
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.)
Re:Once again... /.'ers rally against the cause... (Score:2)
if (new || different) { sucks == true; }
I think that you are exactly right. A GUI is all about offering the user a lot of information quickly and in an easy to understand manner. This will be a move forward. You will be able to create stateful icons that give you a lot of information at a glance. That is what it is all about.
I know that there are a lot of proprietary ways to do this right now but moving towards SVG is a step forward. As one user pointed out, it will allow users to make their own custom icons with custom functionality without really having to program.
A better way to clone the OSX look and feel? (Score:5, Interesting)
Since then I've started running a OSX box as well, and have to admit that I like the look.
Now I wonder -- would it be copyright infringement to write a script that extracted all of the SVG icons from a MacOSX box, copy them to a GTK theme directory, and run them on Linux? Thus the distributed theme itself wouldn't have any of the Apple look -- it would simply have the skeleton. The actual artwork would be copied by the end user in the privacy of their own home or office directly off a OSX box.
The second possibility for this is to be able to run, with almost the exact same look, GTK/Gnome apps on directly on OSX (Apple's release of X11 really is amazingly well done, btw). The X11 integration still wouldn't be perfect of course (apps still have a hard time mimizing to the Dock), but it would be a visual improvement. Or even integrate the ability to search a file's resources to get the SVG icon and display it in Nautilus by default.
In any case, librsvg sounds very promising. I'm impressed.
Re:A better way to clone the OSX look and feel? (Score:5, Insightful)
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.
Re:A better way to clone the OSX look and feel? (Score:2)
Wow. I was under that impression. Thanks for clearing that up! And I have to give credit to Apple for doing an amazing job with their scaling interpolation algorithm. Certainly fooled me.
(PS, moderators -- mark the parent up as insightful.)
the end of diferences? (Score:2, Informative)
Finally, great news for users :) (Score:5, Interesting)
Heck, now the word "resolution" will start to have meaning! Instead of getting more small icons on your screen when going from 800x600 --> 1600x1200, you could get more detailed ones. And if it renders faster than PNG images, then we can have both great looks & high speed. Way to go!
Re:Finally, great news for users :) (Score:3, Insightful)
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.
Re:Finally, great news for users :) (Score:4, Insightful)
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.
Mindblowing (Score:5, Interesting)
Seriously, why not go all the way and question the whole concept of icons?
They could be allowed more degrees of freedom in their representation of a complex data object. Consider a 3D spinning folder icon, which somehow gives you an idea of how much data/what type of data is contained in the folder.
Now THAT would be neat.
Corresponding Browser support? (Score:4, Interesting)
Mozilla (Score:4, Interesting)
I've always thought this would be the coolest thing ever: native SVG in a browser. I've thought of all sorts of great applications of this idea--I do mostly statistical analysis and to be able to put all the output, graphics and everything, into one file in a open, standard format that's read by a browser sounds wonderful.
The problem as I understand it is that the SVG library Mozilla currently uses has a license that's incompatible with the Mozilla license. Mozilla native SVG is available in a separate download and has some functionality, but not anywhere near all of it. I've always thought it seemed a bit strange that someone couldn't find a Mozilla-capable SVG library, or that it would be that difficult to build one (I would help, but I just don't have anywhere near the expertise necessary).
So, this stuff about Mozilla native SVG may seem offtopic, but it's really not, in a way: does anyone know if the library used for the SVG icons has any utility for Mozilla SVG or other open source browser-native SVG projects?
Re:Mozilla (Score:4, Informative)
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.
Svg Developpement (Score:2, Interesting)
For thos who do not understand the value of making Svg work on the desktop, it's because you never worked with SVG before.
I've worked all summer long on a job where i had to make a (sacled down and very acurate) map available via web... and it had to be interactively linked to a database...
Now with fixed image this could have been a real pain, but once the map had been transfered from autocad, it was a simple matter: the text in tha map was clickable!
(well, i did have to write a script [sourceforge.net] to build the Svg from a DXF file and it really needs to be cleaned before i post it)
The biggest problem i had to face was the fact that not a single svg viewer passed the W3c Test [w3.org]. The best one i had at the time (The Adobe SVG viewer) was not capable of anchor viewport (ie, using wahtever.svg#viewportdef to automagicaly load the viewport 'viewportdef')
I just wish the format could be more popular... it could the next flash...
Good news, but it would be much better... (Score:4, Informative)
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.
Try Sodipodi (Score:3, Informative)
One quick question (Score:2)
Re:One quick question (Score:4, Informative)
SVG trade-off .. (Score:2)
It's not clear to me how this could result in a faster desktop, except that it should cause less swapping, and that modern CPUs have power in excess (but it could be the same for the RAM, except that desktop machines are often sold by default with inadeguate RAM supply, mostly for commercial reasons).
The real place where vector-based graphic would be useful is the Internet. Less memory would mean less bandwidth required to transmit the image, and the greather CPU usage shouldn't be noticed, given that when you are surfing you don't care if the other activities on your PC (if any) are a bit slower.
But I wonder if SVG would be much better than image compression in that sense.
Re:SVG trade-off .. (Score:2)
The advantages of resolution-independent scaling, though are huge - and I can see "faster" meaning "renders faster than a scaling algorithim for a bitmap"
Re:SVG trade-off .. (Score:5, Interesting)
I'm not so sure why it would be faster to render the SVG and display the PNG (which needs to be decompressed), but keep in mind that it may depend on the test platform. Under Mac OS X 10.1, a lot of people were using a little command line hack that compressed the frame buffer. The memory bus was a bottle neck, and it was faster to compress and decompress the frame buffer than it was to move the uncompressed frame across the bus.. Just a thought.. CPU cycles are cheap, improve the memory system is not..
What's going on? (Score:5, Interesting)
I can't believe people here have so little imagination. It's almost like they are posting just to get modded up for having a 'radical' opinion. I mean, come on, what's the problem with SVG? It's not like the time spent coding on it is going to mean KDE3.2 will be delayed a month, or that Gnome will have more bugs. This is just one of the many enhancements that make Linux, and software in general, nicer. We should be talking about the fun things we can do with SVG, or the improvements that could be made, or any encouraging notes on it. Not about whether it has a point at all.
Let me illustrate some points for the creatively challenged:
So, onto something more positive: what's the state of SVG in KDE? I really enjoyed it in Gnome 2 for the time I used it, but it was a bit slower when they got large. These speed improvements are certainly good news.
Deformable matching for scalable graphics (Score:3, Interesting)
Deformable matches are used in advanced medical applications between 3d volumetric images: CT, MRI, PET, etc.
Excellent... (Score:3, Insightful)
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
Display SVG (Score:5, Interesting)
If this lib as fast as it claims (at rendering though I doubt parsing), then why not? Windows and other elements in the display would break-down into SVG commands that would be rendered as required. Perhaps it would prove a very efficient way of presenting a remote desktop too rather than sending down bitmaps like VNC does at present.
SVG vs. PNG (Score:5, Interesting)
When it ultimately gets down to it, a PNG file is a compressed bitmap. There is a fixed cost to rendering it, which can be expressed as an amortization of the dimensions of the image. Its just like fill-rate on a 3-D card.
When rendering any vector format, there are many dependencies. Is AA enabled? Which AA algorithm was used? Are they using a scanline renderer, or actually rasterizing each vector regardless of its impact?
The same reason which allows SVG to be faster than PNG rendering is the same reason that other cases will be radically slower: rendering each vector disregards the size of the image being rendered. How can this make it slower? Imagine an image filled dozens or hundreds of times with the same vectors that fill the image completely. Suddenly, we're not having to fill a rectangle, we're having to fill it multiple times in comparison to the png drawing in the same space. And the problem gets worse the larger the destination size.
Using a scanline renderer for vector based graphics has a much better cost comparison to png format, but it will always be slower as ultimately bitmaps can be embedded within vector formats.
As a simpler analogy; the vector graphics are to the transformation pipeline or a graphics card what bitmaps (and pngs) are to the rasterization on the video card. Transformation without rasterization is meaningless, and therefore always going to be slower.
Re:SVG vs. PNG (Score:3, Interesting)
Except that most 3d cards will rasterize them internally and not have to a) use main memory, b) transfer main memory across the bus, or c) involve the CPU in a meaningful way. If a good SVG to OGL or D3D mapping can be found, you most certainly can render it faster than a PNG.
Icon scaling != usability (Score:2, Insightful)
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.
Patent issues all resolved? It _appears_ so... (Score:4, Interesting)
According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l [w3.org]
and
http://www.w3.org/Graphics/SVG/Disclosures [w3.org],
this appears to have been resolved to permit
royalty-free use.
If this is true, that's a real victory for the new W3C policy (and for the world in general). Thanks to all. Please let me know if I'm misinterpreting something.
The best demo i found. (Score:3, Informative)
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:)
Remember the NeXT... (Score:3, Interesting)
Remember how the NeXT boxes had postscript displays? Whatever needed to be drawn on the screen was expressed as postscript, and the display was a postscript renderer. It worked beautifully.
SVG is much more powerful (for desktop things, not necessarily for printing/typesetting things) than postscript. I think this is an excellent step.
Re:Not needed for desktop (Score:5, Interesting)
IF SVG supports raster (pixelbased) graphics, together with the vector graphics (as textures or something), this could be really useful. An ultimate graphics format, the holy grail...
As for not being needed on the desktop. Optimizations are *always* needed and useful. Also, this can finally mean truly resolution independent graphics. Simply know the dpi of your screen and all will always be the same size, independent of grannys old 640x480 and mine 1280x1024...
Re:Not needed for desktop (Score:4, Informative)
It would still be an improvement though.
Re:Not needed for desktop (Score:4, Informative)
Re:Not needed for desktop (Score:5, Informative)
When you get small (Score:2)
Re:Not needed for desktop (Score:2, Informative)
Plus inside applications you tend to only get one size of icon regardless of screen resolution.
Re:Not needed for desktop (Score:3, Insightful)
Re:Not needed for desktop (Score:3, Insightful)
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."
Re:Not needed for desktop (Score:4, Informative)
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.
try running @ quad XGA with 48 pixel icons (Score:4, Informative)
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
Re:OS X (Score:5, Insightful)
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.
Re:OS X (Score:2)
Four: 16x16, 32x32, 48x48, and 128x128.
Re:Expanding Complexity (Score:4, Insightful)
With this you have icons that looks good and in the same aparent size in any resolution
Re:Expanding Complexity (Score:5, Interesting)
I don't see that it makes much sense. after all 16x16 or 32x33 icons have been around fr a long time. they're even-byte things and easy to handle. and they're quick
And so are SVG icons - a lot of the current SVG icons are quick to load (requiring considerably less memory to describe the icon than PNG) and quick to draw with this fast renderer. But that is ignoring the most useful part of describing your screen using vectors, splines, etc. - rescalability. We're all used to being able to switch monitors with different DPI and still have the same physical size font on the screen (so that 10 pt is 10/72 inch high regardless of screen dpi) and it's useful to be able to have icons which behave in the same way.
isn''t a desktop all about making a useful user experience? if I wanted gigantic icons I'd have gigantic icons, and I don't. It seems like extra complexity just for a coding exercise.
For people with normal eyesight, standard 16x16 or 32x32 icons are going to be fine. If you suffer from poor eyesight, being able to have fonts and icons at say 4x magnification is extremely useful. And a big part of the GNOME2 architecture is strongly accessibility orientated so this is a useful part of the puzzle.
Cheers,
Toby Haynes
Session Migration (Score:5, Insightful)
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.
Re:I just don't care! (Score:5, Insightful)
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".
Re:I just don't care! (Score:5, Insightful)
I am not your aunt Tilly people!
Re:I just don't care! (Score:5, Interesting)
SVG puts powerful non-proprietary (bye bye gif) graphics capabilities in the hands of the xml architect. It fills a necessary gap in the XML arsenal. As the other technologies evolve, it's benefits will become more readily apparent. Imagine an XSL transform capable of transforming an XML document containing data into a graphical representation of itself...
Programmable content can be embedded as well in the form of applets and XHTML objects. Apache's Batik project is a good example of what you can achieve. Batik can be found here [apache.org].
'half-blind' (Score:5, Interesting)
SVG is one of the few 'imaging technologies' that has very good support for accessibility. Each drawn object can have a title and a description, so whereas you see a "stuffed garbage can", the braille user-agent would output the desc text: "Garbage Can containing more than 1 MB of trash".
SVG could also be used for an org charts, and instead of having a long 'alt' tag would probably be out of sync with the 'gif', the blind user would be able to read the contents of each box, and depending on how the SVG is structured (with groups and defs), even get an idea of how the boxes are related.
Also, SVG supports CSS, so you can have different stylesheets for different media (screen, printer, cell-phone-screen, and even braille and audio).
As far as an imaging technology goes, since it's just another XML format, you can grab an XML document (say in the Weather Observation Markup Format) and use XSLT to output a nice SVG graphic showing the weather. (In fact, that's one of the example used in O'Reilly's SVG Essentials [oreilly.com]).
I've just started using SVG (with Python) as a way to transform map data from the US Govt and make nice little SVG maps for my browser (kind of like a hand-rolled Mapquest).
Programmers familiar with XML will be able to make some neat (albeit very ugly) stuff. Designers who know the fancier drawing tools will be able to make some pretty nice-looking stuff. Put 'em together and you can have some nice smart graphics. Will it replace flash? Who knows.
Re:I just don't care! (Score:2)
Re:I just don't care! (Score:3, Insightful)
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.
Re:Fat Icons BIG business (Score:2, Informative)
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.
Re:I just don't care! (Score:3, Funny)
How about "SVG's Very Good"?
Re:Too late (Score:2, Insightful)
Re:Too late (Score:4, Informative)
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.
Re:Too late (Score:2)
KDE on the other hand do not support rendering SVG icons, instead they have converted them to PNG and use that. Due to earlier releases of librsvg not being nearly as fast as the current one GNOME used to do this to with the SVG Gorilla theme, which is why you might have heard of the PNG variant called unscaleable Gorilla. With latest advances in librsvg however this is no longer needed nor desirable.
This is a pure troll (Score:2)
Moderators:
"<INSERT FAVOURITE DESKTOP SYSTEM> has supported this for years", is always a pure troll. When it is also totally incorrect it certainly does not warrant a +1 interesting.
And GNOME significantly predates that (Score:5, Informative)
I wonder if KDE is using libsrvg to render the icons, as opposed to some Qt stuff. If so, both environments will immediately benefit.
Re:How can they say it's faster? (Score:3, Informative)
Re:How can they say it's faster? (Score:2)
Re:How can they say it's faster? (Score:2)
Re:Terrible Screenshot (Score:2)
Also the theme is mostly meant as a proof of concept, if you do not like it then feel free to create your own SVG icons
Re:Can Mozilla use this (Score:5, Informative)
Re:Can Mozilla use this (Score:2)
Re:Yeah, but... (Score:2)
GNOME 2's already eliminated that.
Re:nice, but (Score:2)
library. This library is not part of the GNOME 2.2 release however (will be included for 2.4) so the