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."

Comments

Not needed for desktop

[unterderbrucke]

Scalable graphics are nice to reduce processor need for Palm PCs and the like, but aren't needed for the desktop.

Re:Not needed for desktop

[e8johan]

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

[msgmonkey]

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.

Re:Not needed for desktop

[gmuslera]

What about replacing flash animations in web sites with something really standard?

Re:Not needed for desktop

[jrq]

Except, the raster parts of the image will exhibit the same scaling artifacts that are present when scaling PNG images.

It would still be an improvement though.

Re:Not needed for desktop

[e8johan]

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.

Re:Not needed for desktop

[yatest5]

Why not? The scalable aspect means you would only have to supply one icon file for different resolutions.

Wow, lets hope they solve the mass storage problem sometime soon so we can store 4 or 5 copies of each icon.

Re:Not needed for desktop

[msgmonkey]

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.

Re:Not needed for desktop

[mrjb]

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.

Re:Not needed for desktop

[Anonymous Coward]

If SVG reduced processor usage, then it is needed for the desktop. Why? In order to free up cycles for actual tools. I want all the eyecandy of E, but I also want XMMS and MPlayer to run smoothly, Mozilla to render fast, GIMP to run without bogging down, etc. If using SVG to draw the screen does the job, then the desktop needs it.

Re:Not needed for desktop

[Anonymous Coward]

Score -1 clueless. SVG takes more processing power than PNGs, so need more processor power. They take up less space.

SVG icons are great for HIGH-SPEC machines. I have high-resolution monitors (high dots-per-inch). Most GUI toolkits are still in the stone age, worrying about pixel placement. That just doesn't scale (tee hee) for high resolutions - think of paper @600DPI. My current monitor is 120DPI - in future I would hope to have a true 300DPI monitor (I've already got effective 360DPI horizontal resolution thanks to xrender). At 300 DPI, dot-matrix bitmaps just don't work well whether on paper or monitor. Vector graphics do, though. You know the way bitmap fonts suck on paper, so everyone uses Truetype or Postscript? Same thing.

Re:Not needed for desktop

[Anonymous Coward]

hey who are you callin granny

Re:Not needed for desktop

[Alan Partridge]

what? with Microslop gearing up to purchase Macromedia?

standard = whatever Bill Gates says

amen

Re:Not needed for desktop

[CaptnMArk]

It might be wise to use the Windows/OS/2 icon format for the desktop icons. It allows multiple images in one file and should also be fast to load (because png seems to be too slow/unoptimized).

Re:Not needed for desktop

[wombatmobile]

IF SVG supports raster (pixelbased) graphics, together with the vector graphics (as textures or something), this could be really useful.

The SVG spec includes rasters. Check these samples SVG images which use bitmaps:

Magnifying glass example (drag the circles around)
Pixelization example

Re:Not needed for desktop

[ThundaGaiden]

I completely agree , I can't wait to install this , unfortunately I think I might have to wait until KDE
decides to support this in a release version

On a plus side they say in Gnome it's faster using SVG instead of the PNG's that they were using !!!

Very impressive , better grafix , and faster to boot

Re:Not needed for desktop

[Ricky M. Waite]

Flash is a standard you biased motherfucker. Why don't you check out this handy link before you go spouting your mouth off.

Re:Not needed for desktop

[Anonymous Coward]

Read the fucking article, asstwat.

Not only do it render them, but it renders them faster than libpng renders the same images in png format.

Re:Not needed for desktop

[Twirlip of the Mists]

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."

Re:Not needed for desktop

[Twirlip of the Mists]

You should buy a Mac. On a Mac, all the eye candy is offloaded to the graphics coprocessor(s), and iTunes and QuickTime player (those are like XMMS and Mplayer, only you don't have to compile them, and they always work) run smoothly, Safari (like Mozilla, but without the bloat) renders fast, Photoshop (like GIMP, but with real tools and support for CMYK) runs without bogging down, etc.

See, it seems to me that you Linux guys are just trying to reinvent the wheel, here. The problems that you all complain about-- fast graphics, a good desktop environment, media tools, and so on-- have already been solved. The near-universal insistence on using tools that are poor imitations at best can only be described as perverse.

Re:Not needed for desktop

[Anonymous Coward]

If I wanted a proprietary Unix machine I'd call friggin' SGI. If I wanted to buy a Mac, I would have done so already. I haven't You see, I prefer to do things myself whenever possible, mainly because I'm an antisocial, and terminally mistrustful bastard. I prefer to pick out the components I want, put them together with my own hands, and then install the OS myself. I don't trust somebody else to build a machine for me, or to install my software. I'd rather do it myself, so that I know who to blame if something goes wrong. I don't have any objection to compiling; being a programmer it's part of the job for me. I'm not willing to pay for Photoshop when I can make do with GIMP. Besides, I've noticed that commercial software has shitty documentation (as in, written for the scuttlefish in the Great American Heartland). Why should I pay for proprietary software that doesn't even come with a decent manual? Why should I buy a proprietary machine when I can build my own? And why in the names of Azathoth and Jehovah and all the other demons feared by ignorant humans should I pay Apple's inflated prices just because their machines look prettier than The Beast sitting on my desktop?

Re:Not needed for desktop

[Twirlip of the Mists]

You see, I prefer to do things myself whenever possible, mainly because I'm an antisocial, and terminally mistrustful bastard.

You've just summed up the Slashdot mentality perfectly. Thank you.

Re:Not needed for desktop

[pyrrho]

it's not at "true" standard until there is more than one implimentation for the standard.

Is there?

Re:Not needed for desktop

[pkphilip]

I believe SVG does allow embedding of raster images and fonts. Adobe Illustrator and Corel Draw (the new versions), allow export to SVG and some limited scripting facility as well.

Re:Not needed for desktop

[psamuels]

See, it seems to me that you Linux guys are just trying to reinvent the wheel, here.

Of course we are. I don't see why this seems to surprise you, or what there is to ridicule about it. We reinvent the wheel because the existing wheel vendors maintain a hands-off policy and don't let us improve existing wheels. Some people don't enjoy the wheelwright business, but we do, so we hack on those wheels we're allowed to hack on, which is generally the ones we've invented ourselves.

The problems that you all complain about-- fast graphics, a good desktop environment, media tools, and so on-- have already been solved.

Not sufficiently. Fast graphics on OS X? Only if I have a certain type of computer from a certain vendor, purchased within a certain recent past. Good desktop environment? Very subjective - I prefer the minimalist approach myself and do most of my work in text mode anyway. Media tools? I don't see a deficiency in the Unix offerings, except in support for certain proprietary media formats like Sorensen Quicktime, which we have been told we aren't allowed to build.

The near-universal insistence on using tools that are poor imitations at best can only be described as perverse.

Who is insisting on using tools that are poor imitations at best? And imitations of what? I picked a computing environment for a lot of criteria - not least of which is that I'm not boxed in to buying either hardware or software from any specific vendor, by the way - and I use whatever tools seem to fit my needs best, whether they be bought, downloaded or home-built.

Imitation is also not a bad thing. You mention Safari - is it not an imitation of the many web browsers that have come and gone since 1992? For that matter, is not all GUI-based software imitating the GUI-based software of the eighties that explored the bounds of the GUI paradigm and figured out how a raster-based system could be made as functional as the text-cell-based systems of its day? Innovation alongside imitation is powerful indeed. Innovation divorced from imitation, while sometimes interesting, is very rarely practical.

And back to vendor dependence: you seem to be content to sit at your computer and trust that Microsoft, Apple, Adobe and Macromedia will spoon-feed you what you need when you need it. I guess that's fine for you (and for that matter, for most computer users) but it's not enough for me.

Re:Not needed for desktop

[Twirlip of the Mists]

We reinvent the wheel because the existing wheel vendors maintain a hands-off policy and don't let us improve existing wheels.

But that's kind of the point. You're making really crappy wheels, and then bragging about how revolutionary they are. The fact that your new triangular wheel improves on the old square wheel because it has one less bump is not something to be proud of when the rest of us are all rolling around on steel-belted whitewalls.

Who is insisting on using tools that are poor imitations at best? And imitations of what?

I am. Of the commercial products on which the Linux products were based or by which they were inspired.

I use whatever tools seem to fit my needs best

That's not really true, is it? Either Windows XP or OS X would fit your needs better than Linux. This is blindingly obvious. You use Linux for reasons other than pragmatism. Which is, of course, entirely fine, but don't argue that it's a rational choice.

You mention Safari - is it not an imitation of the many web browsers that have come and gone since 1992?

Nope. Features like the bookmark manager and the SnapBack function are entirely new. No imitation going on there.

And back to vendor dependence: you seem to be content to sit at your computer and trust that Microsoft, Apple, Adobe and Macromedia will spoon-feed you what you need when you need it.

Hee hee. Wrap it in whatever loaded language you like. The bottom line is that my computer works better than yours.

Re:Not needed for desktop

[psamuels]

But that's kind of the point. You're making really crappy wheels, and then bragging about how revolutionary they are. The fact that your new triangular wheel improves on the old square wheel because it has one less bump is not something to be proud of when the rest of us are all rolling around on steel-belted whitewalls.

You must be confusing me with someone else. I've never tried to maintain that what I write is better than anything else out there. At most I strive to build something that is better for specific purposes than any other free software out there. If it's also better than proprietary alternatives, great.

That's not really true, is it? Either Windows XP or OS X would fit your needs better than Linux. This is blindingly obvious.

Really? How can this be? As far as I know, we have never met, so I find it hard to believe you have any idea what my needs are. How can it be blindingly obvious that either Windows XP or Mac OS X would fit my needs better than the system I'm typing on now?

I guess you're making the assumption that every computer user wants basically the same thing out of a computer. Apple and Microsoft both proceed on this assumption, and for one or two standard deviations of people, it works.

For a simple yet real-world example of where you are wrong: tell me, which of Windows XP or Mac OS X should I run on my Pentium 166 with its 64 MB of RAM? (Well, I did eventually upgrade to 128 MB, but still.)

You mention Safari - is it not an imitation of the many web browsers that have come and gone since 1992?

Nope. Features like the bookmark manager and the SnapBack function are entirely new. No imitation going on there.

How about features like a <Back> button, or an address bar, or pull-down menus, or hyperlinks that you activate by clicking on them? What about an animated graphic ("spinner") whose animation shows that a page has not completed loading? What about a config option for not loading images, or disabling Java? I have never used Safari, but I'm willing to bet that it has all of these thoroughly non-innovative features.

My point isn't that $BROWSER_OF_THE_MONTH has no new features. Most software has at least one unique feature. Even open-source software, which you seem to dismiss sight-unseen as completely reactive. (Oh, wait - Safari is open-source too. I guess you only think open-source software for Linux is non-innovative, then.) My point, and you snipped it, was that you really can't build software ex nihilo. If you write something that doesn't in the least resemble anything that has come before, it may be innovative, but it will most likely be useless as well.

The bottom line is that my computer works better than yours.

No, the bottom line is that my computer works better than yours.

Oops, unprovable statement. And not only subjective, but even more elitist than I have come to expect from Mac users, if you'll excuse the ad hominem.

Re:Not needed for desktop

[Twirlip of the Mists]

How can it be blindingly obvious that either Windows XP or Mac OS X would fit my needs better than the system I'm typing on now?

Because Windows XP and Mac OS X both do the job of running a personal computer better than Linux does. QED.

I guess you're making the assumption that every computer user wants basically the same thing out of a computer.

Yes, indeedy. Every computer user wants to fire up his computer, access peripherals, and run programs.

tell me, which of Windows XP or Mac OS X should I run on my Pentium 166 with its 64 MB of RAM?

XP. Mac OS X doesn't run on Pentiums.

How about features like a button, or an address bar, or pull-down menus, or hyperlinks that you activate by clicking on them?

Yes, Safari has those.

What about an animated graphic ("spinner") whose animation shows that a page has not completed loading?

Safari doesn't have that. It has a different sort of progress indicator, one you've never seen before. It's (gasp) innovative.

What about a config option for not loading images, or disabling Java?

By "config option," you mean "preference control," right? Remember, Safari is real software, not something you have to compile yourself in order to make work. Safari has a control for enabling Java, but no control for loading images.

I have never used Safari, but I'm willing to bet that it has all of these thoroughly non-innovative features.

Careful. Your ignorance is showing.

Oh, wait - Safari is open-source too.

There it goes again. Safari is not open-source.

Oops, unprovable statement.

No, it's not unproveable. Let's get into it. Name one thing your computer does better than mine. Let's see who wins.

Re:Not needed for desktop

[psamuels]

Because Windows XP and Mac OS X both do the job of running a personal computer better than Linux does. QED.

What makes you think I'm running a "personal computer"? It happens that the hardware I own is marketed as such, but I consider it a development workstation, file server, etc. I think the question of whether Windows XP or Mac OS X are "better" for certain functions depends on how you define these functions. You seem to lump every computer user into a single "personal computer" profile. If you allow this profile to be broad enough, sure it fits. But then, with a broad enough profile, you can't credibly claim that XP and OS X are the best of breed. You're treading a rather thin line of semantics here.

which of Windows XP or Mac OS X should I run on my Pentium 166 with its 64 MB of RAM?

XP. Mac OS X doesn't run on Pentiums.

And neither does XP, with 64 MB of RAM. I'm sure it will boot up, but I expect the combination of slow CPU and (relatively) low memory will cause it to run slowly enough not to be considered "usable" by most people.

To put it in terms you would understand: I'm talking about hardware roughly on par with an early PowerPC 604: a first- or second-generation Powermac. Would OS X run on those, and if so, would it be fast enough to be usable? I have heard that a G3 is considered the minimum "sane" configuration - is that true?

(I don't mean to imply the computer I'm using right now is the Pentium 166. It's actually an early Pentium 4. My P-166 is in the next room, headless, acting as a file and web server. That was my previous desktop machine, though.)

What about a config option for not loading images, or disabling Java?

By "config option," you mean "preference control," right? Remember, Safari is real software, not something you have to compile yourself in order to make work. Safari has a control for enabling Java, but no control for loading images.

Yes, by "config option" I meant "preference control". I didn't mean a cryptic compile flag, or hand-editing a config file. I meant a check box somewhere in a Preferences dialog.

Careful. Your ignorance is showing.

Right, so it is. I haven't used Safari. I didn't know it actually lacked the ability to suppress load images. I also didn't know they had replaced the "spinner" (which my browser also does not have). But you have still admitted that it has many features not invented on the spot, like the ability to follow links by clicking on them, or scroll bars to let you display a document larger than your screen. (You didn't admit to having scroll bars, actually - I'm making another assumption here. I rest assured that you will call me on it if necessary.) It did not burst fully formed from the head of Zeus. Nor did most (dare I say all?) other software.

Oh, wait - Safari is open-source too.

There it goes again. Safari is not open-source.

You called me on it. I hadn't actually checked - I just remember reading somewhere (slashdot?) that Apple was planning to release it as open source. Now I see that while its key components are open-source, the browser shell itself possibly isn't. (The exact difference between Safari and WebCore is not clear to me.)

Let's get into it. Name one thing your computer does better than mine. Let's see who wins.

That's silly. You can't go by feature count. Things that are important to me aren't to you, and vice versa. Some features are available of many platforms but are significantly harder / uglier / more cumbersome on one than on another. (Yes, that street runs two ways, too.) What features are worth counting and what ones aren't would be subject to debate. So, I'll just concede from the outset that your OS has more bullet points of things important to the Average Computer User, by which we mean a standard deviation or two from the average end-user desktop peon.

Also it is not obvious what constitutes a unique feature. A lot of Unix software can be built for Darwin, but many Mac users wouldn't consider this software as "available" unless it comes in prepackaged form. (Of course, a lot of this software wouldn't be considered necessary or relevant for the standard deviation of computer users.)

Finally there is the difficulty that I don't know for sure that certain features plain can't be had on OS X. The one I'm thinking of right now is having about ten 144x72-cell text mode "virtual consoles" to switch between at the touch of a hotkey. I don't know if OS X does text consoles at all, but I suppose it might. (No, drawing a text window in graphics mode does not count.)

Re:Not needed for desktop

[Twirlip of the Mists]

That's silly. You can't go by feature count.

Look, dude. I'm trying to be objective here. I've thrown down the gauntlet. I'm saying that either Mac OS X or Windows XP would do a better job of running your personal computer than Linux does. If you don't want to argue the point, that's fine. I respect that. But don't misrepresent my position. I'm being quite clear, here.

The one I'm thinking of right now is having about ten 144x72-cell text mode "virtual consoles" to switch between at the touch of a hotkey.

Works fine. It's called Terminal.app. And you can have as many consoles of as many sizes as you like, and you can switch between them with a key combination.

No, drawing a text window in graphics mode does not count.

Why not? I'm not arguing that either OS X or XP do exactly the same things in exactly the same way that Linux does them. I'm saying that both OS X and XP do the same job-- running your personal computer-- better than Linux does. If your goal is to have multiple text consoles, then I can tell you how to do that. But if you want to draw an arbitrary line and say, "If it doesn't do it in exactly this way then it's crap," that's fine by me, but don't pretend that you're being honest or fair when you do it. If you want to fall back on arbitrary conditions in order to make it look like Linux wins some kind of objective comparison, go right ahead. I don't think you're fooling anybody by doing so, however.

Re:Not needed for desktop

[psamuels]

Look, dude. I'm trying to be objective here. I've thrown down the gauntlet. I'm saying that either Mac OS X or Windows XP would do a better job of running your personal computer than Linux does.

And I'm saying that for a question like that, there is no objective answer, so you're chasing after the wind and (intentionally or otherwise) manufacturing dogma which you expect to be received as from on high.

A long time ago I read an article in, oh, must have been BYTE magazine, and the author made the point that everything he uses a computer for, he used to do without a computer - write letters, play games, crunch numbers, draw pictures, etc. The computer just made his tasks better, faster, more fun, but didn't actually change the list of things he did in life.

As far as I'm concerned, a similar argument applies to the computing platforms of today. They can all do the basic things people need out of a computer, but any given OS might accomplish certain tasks with more ease and style than its competitors.

Unfortunately for your argument, measuring ease and style is horribly subjective, not at all suited to your vocabulary of "obviously" and "QED".

Back to me and my personal computer, if you insist on calling it that. Most of the things Linux does, I could technically get done on other OSes such as OS X or even Windows XP - thus the reason I can't make a very convincing list of bullet points. But to say those are "better" for the task than Linux is to ignore the whole factor of user preference. The fact is (and now we're getting objective: this is a fact), I like how my Linux box works, a lot better than I like how Windows XP works. (OS X is somewhere in between, thanks largely to its Unix underpinnings.) I don't see why I should care if The International Twirlip of the Mists Standards Body declares that my expectations for how a computer should behave are obsolete and stupid and that I need to be forcefully re-educated in the Scripture According to Steve Jobs for the good of humanity and the gene pool.

If you think about it, most of the distinguishing features between different computing platforms nowadays are matters of style, not substance. Anti-aliased fonts? Pure style - nobody actually needs them, but to some people they look nicer. Vector-based icons? (The point of this story, in case we've forgotten.) Pure style, nobody needs to scale icons on the fly, it just looks nifty and arguably improves your UI reaction times. The "you've got mail" wave file when you start AOL? Pure style. (Negative, if anything, but hey, whatever.) Pretty, "cluelessness-resistant" OS install process? Pure style - any OS that ever needs to be reinstalled, short of total hard drive failure / replacement, is hopelessly buggy and shouldn't be considered as a contender for best-of-breed anyway. A HIG that does its level best to pretend the second mouse button never happened? Pure style - some people swear by it, others (including of course me) find it horribly constricting.

No, drawing a text window in graphics mode does not count.

Why not? I'm not arguing that either OS X or XP do exactly the same things in exactly the same way that Linux does them.

Why not? Because I have tried both ways and I prefer the one, dangit. (Same reason some people use anti-aliased or LCD sub-pixel font rendering.) Because, for almost every graphics card I've ever used[*], the text modes look nicer and are easier on my eyes - and a lot faster to render, switch to/from, and update. And, since the majority of my screen time is spent doing things that don't need a GUI, I really prefer to switch to graphics mode only when necessary.

[*] Yes, there are a couple of unfortunate exceptions. On certain modern graphics chips, VGA text modes are a mere afterthought and don't do the card justice. I try to avoid those cards (ATI, mainly).

What's that you say? I should try a higher-spec monitor? A nicer graphics card? A faster CPU? Nope, remember, we're talking about the computer I've got now. Spending more money to run a Red Queen's Race back to the status quo isn't part of the deal. (Except spending money to buy Windows XP, I guess you would say.)

Re:Not needed for desktop

[Twirlip of the Mists]

And I'm saying that for a question like that, there is no objective answer

Sorry, don't buy it. You say, "My computer does X." I reply, "OS X or XP would do Y, which is superior to X." Repeat. The conclusion? Either OS X or XP is objectively better than Linux. It's easy.

But to say those are "better" for the task than Linux is to ignore the whole factor of user preference.

Yes, that's exactly right. I'm completely ignoring user preference for purposes of this discussion, in order to keep things objective. Personally, I don't like using Windows. I just don't care for it. I think it's ugly, and I find it inconsistent. But that's not an objective argument, so I'm just completely setting it aside. The fact is that both Windows XP and Mac OS X are approximately equivalent in terms of capabilities and capacities. Some tasks are easier to do on one versus the other, but the differences are minimal compared to the vast differences between either XP or OS X and Linux.

See? I'm trying to be objective here, and to prove to you that either XP or OS X is better than Linux. You keep saying you don't want to discuss it in those terms. As I said before, that's fine, but don't pretend that you're being honest or fair here.

Anti-aliased fonts? Pure style - nobody actually needs them

Demonstrably false. One the spectrum of ease on the eyes, you have bad anti-aliasing, no anti-aliasing, and good anti-aliasing. Good anti-aliasing reduces eye strain and fatigue, resulting in a demonstrable, measurable benefit to the user.

Vector-based icons? (The point of this story, in case we've forgotten.) Pure style, nobody needs to scale icons on the fly

Again, demonstrably false. Run your computer at a screen resolution of 3840x2400 (the QUXGA format, if you prefer those sorts of names). Without scalable UI elements, your interface will be unusable. Scalable UI provides a demonstrable, objective benefit to the user.

Not to mention benefits for the vision-impaired. Being able to scale the UI is not merely useful to those people; it's essential. Again, demonstrable, objective benefit.

The "you've got mail" wave file when you start AOL? Pure style.

Are we talking about notification in general, or that particular notification specifically? I couldn't give a damn about what AOL uses for notification, but notification in general obviously provides a demonstrable, objective benefit to the user.

Pretty, "cluelessness-resistant" OS install process? Pure style

So ease of use is, in your opinion, pure style? That's so obviously bullshit that I don't even know if it's worth responding. An easy installation process reduces the time required to get a new computer up and running, and reduces the likelihood of user error during the process. Demonstrable, objective benefit.

A HIG that does its level best to pretend the second mouse button never happened? Pure style

Except to people with limited range of movement, such as young children, older people with degenerative afflictions of the hands, people with repetitive stress injuries, and people (like myself) who hope to avoid repetitive stress injuries later in life. Hmm. That covers pretty much everybody, doesn't it? Kids, old people, people with bad hands, and people who want to avoid having bad hands. Demonstrable, objective benefit.

Why not? Because I have tried both ways and I prefer the one, dangit.

Remember, we're being objective here. I'm sticking to the rules; can you?

Because, for almost every graphics card I've ever used[*], the text modes look nicer and are easier on my eyes - and a lot faster to render, switch to/from, and update.

This says more about your lack of experience with modern hardware, I think, than it does about any objective facts.

What's that you say? I should try a higher-spec monitor? A nicer graphics card? A faster CPU? Nope, remember, we're talking about the computer I've got now.

First of all, if you've gone out of your way to assemble a computer that isn't functioning properly, that's your own fault. You just got through telling me that your computer has a Pentium 4 in it, so unless you've done something squirrely, you won't have any problems with your graphics card.

There is, objectively, nothing wrong with overlapping terminal windows with well-anti-aliased text. And you get demonstrable, objective benefits that your text-console-only system cannot provide, such as being able to see more than one console at the same time.

Getting the theme, here? Demonstrable, objective benefits.

Re:Not needed for desktop

[psamuels]

Sorry, don't buy it. You say, "My computer does X." I reply, "OS X or XP would do Y, which is superior to X." Repeat. The conclusion? Either OS X or XP is objectively better than Linux. It's easy.

You are failing to define "superior". You are letting the term "objectively better" rule by fiat: "xxx feature is useful because yyy, therefore it is objectively better than not having xxx." That doesn't take into account people like me for whom quite a few features in the "xxx" category are either unimportant or just plain undesirable.

Worse, you have a double standard. When I say "I like the way Linux works", I am calling up an aggregate image of features which provide benefits to me - lots of features, most of them too trivial even to mention, but adding up to an experience I want from a computer. Then you say, "Sorry, I'm not talking about user preferences." So therefore for the purpose of your definitions, my user comfort level is irrelevant. Yet, when you start talking about antialiased fonts, scalable UI elements, one-button mouse design that allegedly helps prevent RSI, etc., then suddenly user comfort is considered an objective measure of utility.

You can't have it both ways. You can either concede that many computing environments (Linux included) can provide the same basic feature set for people to get their work done, differing only in matters of "style" and "ease of use" and "comfort" and "efficiency of interfaces" ... or you can claim that personal preference does play a role in whether one environment can be considered "better" or "worse" than another ... thus making the whole thing at least reasonably subjective.

But so long as you continue to say "This is obviously always better than that, QED", then I have nothing left to say to you. Go ahead and get in a last word (and yes, I'll read it), but I think I'm done here.

First of all, if you've gone out of your way to assemble a computer that isn't functioning properly, that's your own fault. You just got through telling me that your computer has a Pentium 4 in it, so unless you've done something squirrely, you won't have any problems with your graphics card.

There's nothing wrong with my computer. Many people would probably be quite happy with the 1600x1200 graphics window I bring up here on occasion. I am not. And I haven't yet seen a computer whose graphics output can match my high-res text mode for readability and general comfort. Maybe an LCD would eliminate the difference, but nothing I've seen on a CRT does.

Re:Not needed for desktop

[Twirlip of the Mists]

So therefore for the purpose of your definitions, my user comfort level is irrelevant.

Boy, are you missing the point.

If you can name some feature or characteristic of your computer that provides you with a demonstrable, objective benefit, do so. For example-- I'm totally making this up, just to explain what I'm talking about-- let's say you're blind, and Linux provides a comprehensive non-visual user interface. Braille, or audio, or whatever. That's a demonstrable, objective benefit. I would be unable to argue with that, and I would humbly admit defeat and shut up.

If, on the other hand, you were to day, "I like pink better than blue, and my computer draws everything in various shades of pink," that would not provide a demonstrable, objective benefit. That would be purely a matter of personal preference. As you so wisely pointed out, arguing about preferences is like counting dancing angels on the head of a pin; it gets you nowhere.

Now do you understand the terms? We're talking about demonstrable, objective benefits. Not preferences. It is not true to say that your "comfort level is irrelevant."

Got it?

But so long as you continue to say "This is obviously always better than that, QED", then I have nothing left to say to you.

Okay. If you don't want to have the discussion, that's fine. But let no one think that I am being anything less that totally fair. I'm trying to get to the objective truth here, and you're not playing along. Which, as I've said many times before, is fine, it's your prerogative, and I'll respect your choice.

Many people would probably be quite happy with the 1600x1200 graphics window I bring up here on occasion. I am not.

Do you have a demonstrable, objective reason for this dissatisfaction, or are we simply in the realm of "I like pink?" Let's separate the objective from the preferential and get down to brass tacks!

Re:Not needed for desktop

[psamuels]

(I swore I was getting off this bus ... oh well, one quick question, one quick answer.)

Many people would probably be quite happy with the 1600x1200 graphics window I bring up here on occasion. I am not.

Do you have a demonstrable, objective reason for this dissatisfaction, or are we simply in the realm of "I like pink?"

I thought I'd mentioned it once or thrice already. In fact, I'm sure I did. I find my high-res text mode more readable and easier on the eyes than any graphics mode I've seen so far. I guess you must think that's a "pink" thing. Well, I think your antialiased fonts are a "pink" thing too - they aren't more readable to me. Actually I generally can't tell much difference. (I'm told sub-pixel antialiasing makes a much bigger difference, but I don't have an LCD.) So between you and me, we still can't agree on what constitutes an objective, measurable and repeatable improvement in user experience. Your explanation is that I just don't get it. Mine is that such improvements are very few and far between, and have basically all been done by everyone years ago - what's left is eye candy and "pink" preferences that one hopes will work for more people than not.

I think the way you and I use computers is so far apart that you're having trouble imagining why I find so many of your gee-whiz innovations useless, boring or even negative. To you it is self-evident ("QED!") that having these features is unilaterally better than not having them. To me it's not. Again, I don't think we're ever going to agree on this. And again, I think I'll shut up now. (Oh - if you're planning to respond - can you please let at least one post go by without the patronising "ok if you don't want to discuss this, that's fine, your prerogative, feel free to keep your closed, illogical mind" line? It's not that I'm shying away from what I feel is an indefensible position; it's that AFAICS you and I have such a high phase mismatch that I very much doubt this is anything but a waste of both our time.)

Re:Not needed for desktop

[Twirlip of the Mists]

I find my high-res text mode more readable and easier on the eyes than any graphics mode I've seen so far.

The only thing that proves is that you've never-- or won't admit that you've ever-- seen properly rendered anti-aliased text.

they aren't more readable to me. Actually I generally can't tell much difference.

Oh, come on. I can understand willful ignorance-- "if I never look at a modern graphical operating system, I can continue to pretend that my circa-1970 technology is superior"-- but this is just silly. If you seriously can't tell the difference between anti-aliased text and non-anti-aliased text, you've got some kind of serious vision impairment. The difference is obvious! Hell, I'll email you a screen-shot if that's what it will take. Oh, wait, that probably won't do any good. You won't be able to view it unless I render it in ASCII-art form. ;-)

To you it is self-evident ("QED!") that having these features is unilaterally better than not having them. To me it's not.

Well, then, offer up some kind of argument for why I'm wrong, instead of just sitting there and going "nuh-uh" over and over again.

Oh - if you're planning to respond - can you please let at least one post go by without the patronising "ok if you don't want to discuss this, that's fine, your prerogative, feel free to keep your closed, illogical mind" line?

Okay, if you don't want to discuss this, that's fine. It's your prerogative. Feel free to keep your closed, illogical mind. ;-)

Seriously, I was hoping we could have a constructive argument on this subject. I really, sincerely believe that I'm right and that you're wrong, and I'd love an opportunity to convince you of the fact. But if you'd prefer to stand by statements like "I can't tell the difference," then it's going to be tough for me to win you over. So it's entirely up to you. Fair enough?

odd

[pummer]

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!

Re:odd

[jordan_a]

Icons are only a small part of what SVG Graphics are about. However being the most common images used on the desktop it is a logical starting point for SVG graphics.

Re:odd

[KDan]

The SVG desktop background they have there is really fugly though. I can't recall ever seeing a vector image that would really look good as a desktop bg... Maybe that's just not meant to be.

For icons, they rock, though. For buttons, menus, etc, they rock too. Just not for "big things"...

Daniel

Re:odd

[olethrosdc]

The SVGs would be most useful for widgets I guess. Now that I think of it, they would be extremely useful for widgets and buttons.

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

[Proc6]

Well dummy, its like this. The higher resolution the display you get, the finer detail images and video (some day) can get. Buuuut... the harder it is to see windows elements of fixed size. (icons) I run 1920x1200 on a flat panel, and when my father sits down in front of it, he has to squint to read the text and see the icons on the desktop. Ever seen 1600x1200 on a Dell Latitude notebook? Go find the IBM QUXGA 22" LCD panel that does something like 5000x3000 and tell me how big the icons on the desktop are. Its like clicking on dust.

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

[Anonymous Coward]

Wel, what is the cpu power for these gadgeds?

Does it mean i have to have a powerfull system for this stuff.

CGI has it already, why don't they share the stuf with OSS comunity. Because they are a bunch of wankers!

And why the hell is it LGPL?

Re:odd

[jordan_a]

Well I agree that that image was pretty flaky, but I wouldn't blame that on it being SVG. That image is a common PostScript example, it was probably just converted to SVG. Also keep in mind that this lib still doesn't pass most of W3C's SVG tests. For some nice examples of larger SVG's you could check out Batik

The most exciting thing I think SVG could bring to the desktop though is a rendering system as powerful as NeXTStep and Mac OSX.

Re:odd

[Anonymous Coward]

Just an observation - if you make your screen twice as wide and twice as high, you get four times the screen area. If you then resize your windows and icons so that they are twice as wide and twice as high, you end up right back where you started.

Which is rather pointless, don't you think?

Especially since larger resolutions take significantly more memory and cruntwork to display and update (your 22" LCD screen is eating 58Mb of video memory and the video bandwidth is astronomical).

What's the ---ing point?!

Re:odd

[Proc6]

Pointless unless you like crystal clear pictures and razor sharp text. Compare a 1600x1200 monitor with laser printed paper sometime.

Re:odd

[brother rat]

and don't forget the "Marlett" font in windows. It may well be one hell of an ugly hack, but it serves a very similar purpose.

Re:odd

[Lucas Membrane]

I'm a little ahead of the baby boom, so my eyes are a little worse than those of most people, but they are catching up. This is something that is long overdue and will be most valuable or just about essential as the demographic bulge moves into its later years. We can't go on creating every UI like it was designed by a 22-year-old with no idea that vision doesn't deteriorate for some of us. It's just about criminal that if you are having trouble reading the screen and go out and buy a better, higher-resolution monitor, everything gets harder to read.

Re:odd

[Anonymous Coward]

Hell, my vision's been fucked since I was 11.

Re:odd

[Sparr0]

Well, ALL true-type fonts are a sort of SVG. And I've seen some that only display their true level of detail at 72+point size. This is a very good thing for many types of graphics, particularly any sort of chart. Basically this takes part of the 50% of images that deserve to be PNG/GIF compressed instead of JPG compressed.

Just more OSX themes.

[Sh0t]

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

Re:Just more OSX themes.

[rseuhs]

Unlike most eye candy, this makes the desktop faster, so I don't see anything wrong about it.

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.

[Anonymous Coward]

You should look at the possibilities BEYOND icons...

cat pr0n.gz | gunzip | svgviewer

"mmmmm, scalable porn...."

Re:Just more OSX themes.

[Anonymous Coward]

That Gnome desktop looks like complete ass.

Re:Just more OSX themes.

[Enahs]

Agreed. The only focus seems to be on making GNOME just a little bit better from a user perspective than KDE. Sometimes they do okay, and sometimes they fail miserably. Most themes seem designed to show off whatever new pointless feature someone's come up with.

I can see a need for SVG, but not for SVG icons.

Re:Just more OSX themes.

[Anonymous Coward]

Is that your desktop?? It's ugly as hell!!

Re:Just more OSX themes.

[Fastolfe]

Most UI elements today make one horrible assumption: that the pixel resolution the user is using allows a 64x64-pixel icon to be viewed comfortably.

We already have displays today where this assumption fails, and where fixed-pixel-size icons are far too small to be usable. In the not-too-distant future, our computer displays won't be measured in pixel dimensions, but by real-world dimensions and a DPI value.

We already have vectored text today, and we need it, especially in the print business. A 12pt font should look exactly the same size on every monitor, regardless of what resolution you're running at. It should just be clearer and sharper at higher resolutions. Graphics should be the same way. Today, they're not. On high-resolution displays, the text may appear about the same size, but now you have all of these graphical elements that are disproportional. SVG fixes that, and icons are a great place to start.

Re:Just more OSX themes.

[Greedo]

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.

Re:Just more OSX themes.

[DataPath]

This has nothing to do with pimping GNOME. If SVG really does render faster than equivalent pngs, plus is fully scalable, it will probably make its way into KDE also, and anything that a) makes the UI faster, and b) makes nicer UIs less intensive is good for every non-proprietary OS. The nice thing about SVG for UI elements is that it would mean no longer including different sizes of wallpaper - one would work fine, without lossy resizing. The implications on the desktop are endless. This is a Good Thing(tm) for everyone.

Re:Just more OSX themes.

[perlyking]

You have desktop icons? Pffft, fancy shmancy ;-p

Re:Just more OSX themes.

[Anonymous Coward]

It stop people having to redo ALL the icons every 3 years as people's resolutions go up. Think about all the duplicated graphics that has to be done so that icons look good for every resolution. Stuff that. Do it once in SVG and forget about it.

Re:Just more OSX themes.

[t]

No one will ever need more than a 128x128 pixel icon.

IBM made a 400 dpi monitor once and said they had no plans on marketing it because MS Windows couldn't scale properly. The old 32x32 pixel icons would have been about 20 mm square. Think you can still click on it? To be fair, the larger 128x128 icons are almost a centimeter.

The goal is to one day have tablet computers with screens that have resolutions of around 600dpi so that they look like paper. All this talk of antialiasing is merely a method to alleviate the lack of a proper resolution. It's kind of like disk doubler in the old days of teeny harddrives.

Re:Just more OSX themes.

[Twirlip of the Mists]

IBM made a 400 dpi monitor once and said they had no plans on marketing it because MS Windows couldn't scale properly.

You mean this one? It's 200 ppi, not 400 ppi, and they've been selling it for a couple of years now. ViewSonic also sells a version of it.

I know a radiologist who lives in Italy and works for a US-based firm-- I'm not sure if it's a hospital or a practice or what, I've never been clear on that. He has one of these monitors at home. Because he lives in Europe, during his day it's night in the US, so they email him digital images of CT's and whatnot and he reads them on this great big monitor. I've seen it in action once; it's like looking at real film on a real light-box. It's incredible.

Re:Just more OSX themes.

[Dunkalis]

KDE already uses SVGs, in the default Crystal SVG theme, in KDE 3.1.

Re:Just more OSX themes.

[Anonymous Coward]

http://sodipodi.sourceforge.net/showsvg.php3?file= gallery/ain/bishoujo09.svg

Re:Just more OSX themes.

[PurpleBob]

Um... 20 mm is bigger than a centimeter. It's two of them, in fact.

Re:Just more OSX themes.

[DataPath]

Rock on. SVG will save the world!

gnome armageddon

[Trolling Thunder]

this is the sixth text revision done on 04-11-2002.

dear reader the gnome armageddon has started,

first of all i want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it. belive me it took me a couple of days writing this text in a foreign language. even if you don't care at all for gnome, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

on the following lines i'm trying to give you a little insight of the gnome community. the things that are going on in the back, the information that could be worth talking and thinking about.

many of us like the gnome desktop and some of us were following it since the beginning. gnome is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of u*nix. only to name some of its advantages.

unfortunately these advantages changed with the recently new released version of gnome. the core development team somehow got the idea of targeting gnome to a complete different direction of users. the so called corporate desktop user. in other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting gnome on their computers.

having this new target in mind, the core development team mostly under contract by companies like redhat, ximian and sun decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. so far the idea of a clean easy to use desktop is honourable.

some of the new ideas, features and implementations such as gconf, an evil windows registry like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that gnome leads and the attitude of the core development team made a lot of users really unhappy. these are only a couple of examples and the list can easily be expanded but for now this is enough. now let me try to get deeper into these aspects.

you may imagine that users got really frustrated because their beloved gnome desktop matured into something they didn't want. during the time, the frustration of a not less amount of people increased. more, more and more emails arrived on the gnome mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

but the core development team of gnome don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. the reply they give is mostly the same. users should either go and 'file a bug' at bugzilla or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback isn't appreciated.

if you gonna think about this for a minute then things gonna harden that they are directing into the commercial area. the core development team actually don't care for the complaining home user. it's more important for them to reach the customers with the cash. it seems that this has been told to them by the company leaders. everything about gnome has been decided already, a way back or direct communication isn't possible. don't get trapped by sentences like 'we listen to our users'. they listen to you - yes, to make funny silly jokes about you afterwards.

i thought that everything was build up on friendship, build on programming for fun, build on understanding each other. but the reality looks like it's all for the big money. the cash is what matters everything else is a lie and a dream. time for people to wake up.

not long ago they threw one of the most important long year core developer martin baulig out of team. a guy who worked really hard on getting gnome into the right direction. a nice friendly person who put all his time into gnome. but narrow minded gnome elites such as havoc pennington were responsible that he left the gnome project. the trouble and the pressure that was put on him was to much.

with the new gnome desktop a lot of user interface changes happened such as button reordering. needless to say that this confuse people who are used to the 'right' button ordering for ages. even our fellow linux guru alan cox wasn't thrilled about this idea. but the gnome elites such as havoc pennington, seth nickell, calum benson and dave bordoley knew it better. why following the road of any other desktop that exists ? why not doing something that don't confuse their users and still stay usable ? well it seems to be too easy. gnome needs to be different than anything else so they changed the button order which was one of the reasons that users became unhappy. they said that there was a hard fight about this and the decision was made to change the buttons. but i belive they simply copied the behaviour of macos because most of the gnome developers use a macintosh as either laptop or desktop. sad that they forgot to keep in mind that users tend to mix applications and that this will lead into weird button searching and clicking.

but as if this wasn't enough the same people decided that the new gnome human interface guides were the ultima non plus ultra in human interface guides. the announcement contained informations that the kde usability people got initiated into it. unfortunately the kde people heard about it the first time when seth nickell went to the kde mailinglist which happened after the announcement. you can imagine that they got highly pissed off about this attitude. you can read more on this link. to summarize it, the kde people clarified that gnome should care for their own business.

the problem that came with the new interface guides was, that every little gnome hacker started to become an user interface expert over night. a lot of gnome programs that we like to use matured into a disaster over night. hackers that never programmed correctly for their life started to blindly follow the hype of simplification. for an example look what happened to galeon's interface (pay attention for the last paragraph). even philip langdale a long year galeon hacker got highly indignant by the target that gnome leads and wrote this email to the galeon mailinglist.

here another reason why users became angry. the elite assumes, that the user knows nothing about their system. you find a couple of heavily insulting mails on their mailing lists containing sentences like the quoted ones.

• "the user don't know what a window manager is"
• "the user don't know what themes are"
• "the user don't know what a homedir is"
• "the user can't compile a kernel"
• "the user don't want to customize their desktop"
• "the user shouldn't see preferences which purpose they don't know"

you may imagine that a lot of people are being offended by such lines because it's exactly these gnome users who are meant by these phrases. to read more such lines on the gnome mailinglists, simply click on this link and grep in their archives. be said that most of these sentences are coming from havoc pennington.

such evil practices shouldn't be tolerated by the users and need to be fighted. u*nix users aren't stupid people. who actually gave havoc pennington the rights to decide what the user wants and what not ? various users told him that people who use a u*nix like system are well aware of their capabilities dealing with such a complex system. there's a reason why people are switching from alternative operating systems. they want to learn, they want to use the full power of the system, they want to change everything they like.

to top all this, look at the future plans of nautilus. the current maintainers got the idea of changing the whole nautilus concepts into an object oriented user interface design. you may be highly interested in reading the exact words of alex larsson's vision for nautilus' future direction by clicking on this link.

to summarize it, it's assumed that the user don't need to deal with his homedir or his whole filesystem because it may confuse him or because he don't understand it. the new concepts of nautilus should be that the user deal with symbols in the nautilus view. e.g. you get a cdrom symbol and by clicking on it you see the directory of your cdrom, you get a photo symbol and by clicking on it you get a list of all your pr0n pictures, you get a music symbol and by clicking on it you get a list of all your mp3's. you don't know where all these files are located because you don't deal with the bottom layer of your homedir or filesystem anymore as mentioned earlier.

the question is why are people that know nothing about their users, that know nothing about correct user interface design destroying gnome ? the users don't deserve all this specially those that backed gnome for all the years. even sun threw a bunch of so called user interface experts together and have them work on gnome. don't forget that sun are the creators of the common desktop environment. we don't need another cde clone named gnome. even havoc pennington author of the good user interfaces text isn't able to get his own written software following his rules.

not long ago there was an report about the 'two captains of nautilus' where the reporter (uraeus a gnome contributor himself) reported alexander larsson and david camp. you may imagine that such a report can't be taken serious because it's done by their own people. we here have a saying that sounds like this 'one crow doesn't hack the eye of another crow out'. now you can click on this link and read more. it may be interesting to read the replies from various users all over the globe of what they think about gnome and nautilus in general (please pay attention to the listed ip's there). another nice and informative reading can be found by clicking on this link.

the fileselector problem was a long discussed issue in the gnome community. finally they came to an solution for this and have decided to go for this ugly fileselector instead going for this one which was developed by a free volunteer for a long time and in general looks and behaves better.

most users have no problems with the idea of keeping things simple and clean. removing some not needed preferences was indeed a good idea but it doesn't stop. people started to remove everything from their apps. you're forced to use dubious programs like gconf-editor which basically works like the windows registry editor, to tweak uncommented preferences. i don't think that this is an advantage. even the possibility to tweak preferences with an editor was taken away with that ugly implementation of gconf. all your preferences are stored in a directory tree with an unknown amount of *.xml files. even if you delete programs their keys are still remaining orphaned in these trees and finding them is like playing trivia. at the end it's worth a discussion if a system driven by a single home user needs such a registry like system. we didn't need such a system for over 30 years but the gnome development team got the idea copying one of the most retarded systems from windows to u*nix. not to mention that the copy is more retarded than the original.

it's a shame to see how such a nice desktop got thrown into the trash by such people. but there is a lot more behind the scenes that i don't know about. everything around gnome is a big marketing strategy. poor people are working the hell out of gnome for nothing and companies such as those mentioned above are getting the big cash. for sure you could say - go and fork gnome - but seriously how can you go and fork gnome ? such a big project which needs a bunch of people to keep the code alive and compatible. well you know it's all about open source the code is signed under the gnu/gpl or gnu/lgpl, you can't own it. even the companies are aware of this. but if you can't own the code - go and hire their developers. you can direct them like puppets in any direction that you - as company - like. exactly this is happening with gnome.

well you could easily come up and tell me to simply not use gnome and let them do whatever they like. well, you are right with that but things are more complicated nowadays. gnome is influencing a lot of third party projects such as xfree86 which recently added a lot of gnome components into their cvs repository. please know that with the next coming xfree86 version you get a lot of gnome components without even knowing it. code like, gnome-xml, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into gnome development. also the gimp is maturing more and more into getting the look and feel of a native gnome application. the cvs version of the gimp has a lot of gnome pixmaps inside and they are heavily working on integrate the gimp into gnome. if not today but the direction is sure and i fear the day this gonna happen.

it's ok that these things exist and it's ok to see xfree86 and the gimp are beeing hacked on. but please think about the people that don't like or use gnome. what about them ? why force them to have gnome components installed on their systems ? why can't gnome go the same way that kde went e.g. doing their own stuff without infecting other projects like aids. seeing more and more libraries and applications that were in no way related to gnome jumping on the pkgconfig boat which's really not needed. look what will happen to solaris, the world famous operating system on u*nix used by big companies and long years experts. they really plan to replace cde with gnome. i know that cde wasn't the best invention of desktops but it rarely crashed and it fits far better into the philosophy of xfree86 with their configuration system than gnome. you know the good old way having your settings defined with .xdefaults and all nice default configurations are going into /etc/x11/app-defaults/ and so on. understandable that the good old way may be blocking the future of applications for multiusersystems - but why must it have to be a windows registry like system that replaces future configuration ?

well to come to an end i personally don't like many of this stuff. i can't stand the button reordering, i don't like the gconf system and even more i don't like the commercial outsourcing of gnome and the bad influence that gnome has on other applications. the bad attitude of some gnome developers is another story since we are all different reacting humans. luckily there are people sharing some of my thoughts otherwise i wouldn't be able to proof my text with so many links. even amongst the gnome developers there are silent voices of people that hate many of these decisions and silently use something else. right now if you checkout the gnome cvs repository every day you find out that the whole gnome development seemed to came to an halt. the contributions to their cvs are poor. while projects such as kde are reaching easily 10-20k commits per month - gnome is getting around 1-2k per month on it's best times. it really looks like the situation of gnome is unclear so it would be better to have it not influence so much other programs or at the end we deal with an disaster.

now i hope this text was informative for you. i hope that you start to think about the situation and the global direction. the situation of gnome is unclear, their target is groggy too since i can't belive that the users that they are targeting ever heard of u*nix or linux. they plan to get out of the 0.05% desktop niche but this will for sure not happen if they continue their current direction and their bad ugly

Re:gnome armageddon

[Anonymous Coward]

I would have read your post were it not for your lack of capital letters and punctuation. You are not e e cummings. You are not a beautiful or unique snowflake. Learn to write English, and you may-- may-- be taken seriously.

This is a great thing!!!

[md17]

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!

Re:This is a great thing!!!

[Anonymous Coward]

I look forward to the day when there is no more Flash because SVG is so well supported.

haha, don't hold your breath

Re:This is a great thing!!!

[archen]

Flash does more than graphics you know. There's the music, and the scripting as well. As far as I recall, none of that has anything to do with the SVG standard (which of course it shouldn't).

Re:This is a great thing!!!

[Anonymous Coward]

OK, I've answered the same question before...

Flash *is* open. Just check openswf.org.

The problem is, there are not much SWF implementations. Yes there is SWF (writing) support in PHP, and I heard about an open source flash plugin, but I do not expect it to become part of GNOME anytime (not even soon).

Re:This is a great thing!!!

[BigJimSlade]

I look forward to the day when there is no more Flash

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.

Re:This is a great thing!!!

[Anonymous Coward]

Flash does more than graphics you know. There's the music, and the scripting as well.

You can use SMIL with embedded SVG for that. That way you're using nothing but W3C recommendations.

Alright!

[worst_name_ever]

Another major step forward for triangle-shaped icon technology!

Soon you'll be able to have a desktop full of icons that are whatever low-polygon-count shape you want! I'm talking triangles, squares, trapezoids, you name it... aww yeah.

Re:Alright!

[Anonymous Coward]

Bézier curves too don't forget.

Re:Alright!

[TheSunborn]

Why lowpolygon? My ATI Readon 9700 should be able to draw > 10000 polygons widtout slowing down. Remember it don't even have to calculate light source.

Stateful Icons?

[Masem]

Could this also be used to build 'icons' with stateful representations of the objects they are supposed to represent? For example, instead of just 'empty' and 'full' for Trash/Recycle, could you have folders icons that have 'empty', 'sparse', 'full', and 'stuffed'? Or icons that reflect the read/write nature of the folder with respect to the user? Or even more down the road, icons that aren't pointing directly to files/folders but as system objects (as say down the /dev tree), such as a clock, a CPU meter, etc...? Yes, we have that functionality through many means, such as WM's dockapps, or by using shaped windows to simulate that. But if you look at the Mac OS X Dock, or the various things you can do with ObjectDesktop by StarDock systems on the Windows side, they reflect the ideas that I'm thining about here. Sure, it's nice to have, in WM , the status of my system along the right side easy to see, but I'd like it better if I could have a better control over how those are appearing on my desktop, and if I could make them true icons, draggable and placable whereever I want, that would be great.

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?

[Anonymous Coward]

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.

Re: Stateful Icons?

[Anonymous Coward]

I like his "stuffed folders" idea, though, and I can't think of anything that currently supplies functionality like this.

Re: Stateful Icons?

[Textbook Error]

Same idea in Mac OS X - which calls them "badges". The API lets you composite one icon reference on top of another and draw it as a single entity (or to find out if an icon reference is actually a composite).

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?

[jonr]

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.

Re: Stateful Icons?

[jorleif]

Personally I suspect there's not a great deal of point in making icons vector

I agree but this is a step towards an all vector desktop which could have lots of cool applications for instance a zoomable user interface or something similar.

Re: Stateful Icons?

[IamTheRealMike]

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.

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?

[Ed Avis]

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.)

Re:Stateful Icons?

[tigersha]

The sweet part about this is that the icons do not have be an on-off affair. For instance, an emblem is an overlay that is either there or not. With this, it would be possible to dynamically scale the icon depending on some state. For instance, drawing an icon that has a sliding scale for each disk depending on the precentage of space left would be possible. One could have a sort of parameterized icon.

The icon could even change color, for instance it could gradually go from red to green through HSV space depending on the fullness of the disk (green at 0%, red at 100% and some inbetween color inbetween).

Re: Stateful Icons?

[Gordonjcp]

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)

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?

[Tokerat]

One of the first things that popped into my head was read/write lights for hard disk icons. Wouldn't that be a nice way to observe server activity at a glance, just take a quick peek at which icons are blinking on the desktop.

There are a million poissbilities for this, and I hope little things liek this begin to get us re-thinking the whole desktop model.

Re: Stateful Icons?

[ajs]

The main reason to do this is rendering speed. Storage size is also smaller, but really you care about the rendering speed of having 5 apps open, all of which use dozens of icons (I'm running galeon, and I count 16 icons in it alone... galeon tends to be light-weight when it comes to baubles compared to say, a spreadsheet).

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?

[Textbook Error]

So is the scaling algorithm more or less expensive than the SVG renderer?
On a desktop CPU, scaling a bitmap will probably be cheaper - either by using a vector unit like AltiVec, or by clever use of a GPU (like Mac OS X's Quartz Extreme - although that's really used for compositing rather than transformation at the moment).

What about CPUs with no hardware floating point (goes for both SVG and bitmap)?
I suspect bitmaps would be faster - scaling can be done with two lookup tables (one for each dimension), which are either pre-calculated with a real FPU or set up at run-time with fixed point.

What about scaling to print?
Yes, a vector image is more suitable for this case. But icons just aren't printed all that often - certainly not nearly so often as "pictures".

There's no hard and fast line between an icon and a picture, but icons have a fairly well defined role in current user interfaces: they're small pictograms displayed on screen (and even assuming monitor resolutions keep increasing, 128x128 or even 256x256 is going to be big enough for a while).

Of course, since SVG can contain both vector and pixmap data you could use it as a container for either form - depending on what you need it for. I suspect pixmaps would be more common however: the way most people generate icons on Mac OS X is to start with a photo or a screenshot, rather than working in Illustrator and rasterizing at the end (although, true, some people do that as well - their icons tend to look a bit over-Aquified though).

Re: Stateful Icons?

[Lussarn]

One other things that would be awesome with all vector desktop is printing. That could be just gorgeous with printing your desktop in true 600dpi.

Re:Stateful Icons?

[smallpaul]

Consider this: if an icon is "just" an SVG file, and it is becoming increasingly common for applications to represent visualizations of information as SVG, then it starts to become possible for an icon to be just a visualization of some data. The beautiful part is that you don't need any more complex "protocol" between the desktop and the app than simple Unix file paths and streams. The desktop would just watch the file and update its view when the file changes.

Re: Stateful Icons?

[Anonymous Coward]

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).

Start using SVG on the web as well :)

Re: Stateful Icons?

[oever]

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.

KDE has KSVG.
It's pretty advanced too and supports scripting.

Re: Stateful Icons?

[JohnFluxx]

Agreed. In fact this was one of the drives of Berlin.

Re: Stateful Icons?

[Quazion]

But when i switch to a difrent resolution i hope to get more room, i dont buy a bigger screen for more detail, i want more work space.... but then i have multiple monitors, but still i dont think your point goes up always. But rescaling like i want would be nice :)

Re: Stateful Icons?

[Anonymous Coward]

Same idea in Mac OS X - which calls them "badges".

Badges? We don't need not stinkin badges!!

Re: Stateful Icons?

[Fastolfe]

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.

Re: Stateful Icons?

[Fastolfe]

...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?

Re: Stateful Icons?

[Anonymous Coward]

Sure, why not - consumer display resolutions have come from about 640x480 to ~1500x1600 in the last decade or so.

Even assuming a doubling of resolution in the next ten years, which is pretty optimistic IMHO, it'll be a while. We'll need something better when we've all got BillionxBillion holographic displays, but that's a long long way off...

Re: Stateful Icons?

[Anonymous Coward]

Theoretically SVG could be rendered on the fly with XRENDER or OpenGL - so no Pixmap storage overhead. GNOME idiots seem to treat X as a dumb framebuffer though, so I expect they'll continue to misprogram X and complain about it's slowness...

Re: Stateful Icons?

[SideEffects]

"128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes) seems to cover pretty much everything."

Yeah, and we'll never need more than 640K either.

Re: Stateful Icons?

[Iscariot_]

I disagree a bit. Part of the point of using a higher resolution (at least for me) is not just increased image quality, but smaller icons and text... etc. I don't want to see a entirely vector-based OS anytime soon please.

Re: Stateful Icons?

[spitzak]

Although certainly scalable graphics would be great and very useful for a lot of things, I do believe that most users nowadays fully expect everything to shrink when they raise the resolution, and that they actually desire this result and making the system do something else would not be user-friendly.

Re: Stateful Icons?

[Minna Kirai]

You want smaller icons and text? Once you get a vector-based OS interface, you can reduce the size of user-interface elements without needing to change your whole screen resolution.

In the best system, the sizes of UI controls and the pixel-resolution of the output device should be completely decoupled, so the operator can fine-tune each one however he likes.

Re: Stateful Icons?

[ajs]

I must be missing something fundamental to XRender. It's mostly focused on anti-aliased fonts and alpha blending both of which it will be used for by Gnome when XRender adoption becomes a bit more universal (Sun (Solaris 9) and XFree86 (version 4) are, AFAIK, the only X displays to offer this extension currently). XRender's big advantage, in fact, is that it doesn't require you to interact with X in a radically different way.

Suggesting that not using such a sparsely available and relatively new technology to do something that it's not intended for is "misprogram[ming] X" seems to be way out of line to me.

OpenGL is not the right way to go, as it's designed for an entirely different purpose.

The correct solution is to re-think the way X works (specifically with regards to XImage data, Colormaps, Fonts and drawing primatives), and design it to use modern graphics cards correctly. That's not going to happen tomorrow, but it is happening. KDE/Qt and Gnome/GTK+ will take advantage of such features at the become available.

Re: Stateful Icons?

[gottabeme]

Elements shrink in inches, not pixels, when you increase resolution. The elements stay the same size in pixels, which is the measurement the computer uses for on-screen display. You get more room at a higher resolution because there are more pixels on the screen.

Re: Stateful Icons?

[Fastolfe]

I just said things shrink, not consume fewer pixels. When you increase your display resolution, things appear to your eye to get smaller (and free space, from your eye's perspective, appears to get larger).

Re: Stateful Icons?

[Anonym0us Cow Herd]

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.

I disagree. Vector graphics, if you have a fast renderer, are always more desirable than a grid of pixels at a certian size. A vector graphic is infinitely scalable.

You mentioned Mac OS X. But you didn't mention is how beautifully it's doc bar works. As you hover the mouse across it, the shape of the bar distorts and icons scale up, sometime to take up a significant fraction of the entire display. The icons always look beautiful. Not some 32x32 chunky pixelated icon scaled up to 500x500 as the mouse hovers over it. (Before non OS X users complain, this is a temporary (like pull down menus) but beautiful effect that happens as you run the mouse across the icons in the doc. Much better design than the Windows taskbar -- if you have, say 25 applications running at the same time.

If I print a directory listing of files, I want the icons to look beautiful on the printout, or in a PDF. The whole point of vector graphics is that they are infinitely scalable.

Now that we live in the day of plenty of power, and fast vector renderers, with standardized representations for vector graphics (SVG), we should strive to eliminate ALL small pixmap graphics from user interfaces. Not just icons on the desktop, but toolbar icons, widgets, etc. Then the entire user interface becomes infinitely scalable. Even for the person with poor vision who runs at 800x600 because "everything is too small when I run at 1920x1600" can run their display at 1920x1600, and scale up the entire UI so that it looks beautiful, making everything easier to see. Everything would be the same size on the tube as at 800x600, but not pixelated as much.

Scalable vector fonts help in this regard.

In fact, wouldn't it simplify system configuration a lot if the monitor just naturally ran at the highest possible supported resolution? You just go to the control panel to scale up or down the size of the UI elements, including text of menus, titlebars, buttons, etc.

Re: Stateful Icons?

[Speare]

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?

[tunah]

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).

But SVG can be used on the web, too, and with generic CSS styles (font-size:x-large etc) and no more pixel based layout (points is fine), then this problem should also go away. In theory ;-/

Re: Stateful Icons?

[Textbook Error]

As you hover the mouse across it, the shape of the bar distorts and icons scale up, sometime to take up a significant fraction of the entire display. The icons always look beautiful.

Yes, and it's all done with pixmaps - the largest style of icon applications can currently provide on Mac OS X is 128x128x32.

Larger icons may be more necessary over time (although display resolutions aren't increasing dramatically - it'll be a while before you get 5000x5000 on a consumer CRT/LCD), however Mac OS X manages quite well with 128x128. They undoubtably looked at using PDF for icons within Mac OS X as well, however the benefits are pretty marginal today.

Re: Stateful Icons?

[Quazion]

Nice, yeah i understand and agree, never looked at it in that way, personaly i own a copy of Mac OS X so i see your point also i have IRIX 6.5 running so i know how it works. i was foolish *bows*

but atleast i made you write this great comment to explain why we need a vector world for our computer displays :)

Re: Stateful Icons?

[Ed Avis]

I think we will see 'raising the resolution' become an uncommon operation, since most displays will run at the maximum possible resolution all the time. (For LCDs, you run at the natural resolution of the screen, and it makes no sense to use anything else.) Instead there will be an option in the control panel to 'make things bigger' or 'make things smaller'.

When I installed Linux-Mandrake it defaulted to 800x600 resolution, even though the video card and monitor were capable of much more. But it was a sensible default, since current X11 desktops have (physically) bigger UI elements at low resolutions, and might look too small and fiddly at high resolutions (at least for the new user). If, OTOH, you could trust the desktop and applications to just display at the specified size regardless of pixel resolution, then Mandrake could pick the best quality display without any worries.

Another argument is *say what you mean*. If you want smaller fonts and UI elements to give more space on your desktop, then there should be a preference for 'make the UI smaller'. And if you want to change the number of pixels fitting onto your screen, there should be a preference for that. It doesn't make sense to muddle these two things into a single option, still less to have them in a single option and then various kludges like Windows's 'small fonts / large fonts' option on top.

I think that inexperienced users do not raise the resolution, they may not know what the resolution is. And power users will be just as happy with two options 'raise resolution' and 'make stuff smaller'. I don't think it would be user-unfriendly to replace the current broken system.

BeOS also

[Anonymous Coward]

BeOS also can have SVG icon with a special version of OpenTracker.

Expanding Complexity

[amigaluvr]

This sounds like complexity is getting more and more. What about the processor needs required to expand things like this?

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

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.

perhaps it has some other uses though

Re:Expanding Complexity

[gmuslera]

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

Re:Expanding Complexity

[tjwhaynes]

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

Re:Expanding Complexity

[skington]

You can easily cache bitmap renditions of vector icons such as these if that makes things quicker. OTOH, if you've got something like Mac OS X's magnification of icons, it might be quicker to re-render vector graphics every time.

That's an implementation detail, though. The main point is that you can design an icon without thinking of which resolution it's going to be rendered at. That also means future-proofing your design - icons have been getting bigger and bigger as screens get larger. Compare the icons used in Mac OS 9 / Windows 95 to the ones used in Mac OS X / XP. The old ones are *much* smaller, and look ugly when scaled up.

Re:Expanding Complexity

[TheRaven64]

I was at a talk given by a Ximian employee last year, who was showing the functionality of nautilus, and one of the things he showed was scalable vector icons. It made his P800 laptop slow to an unusable speed. Just what we need...

Re:Expanding Complexity

[Anonymous Coward]

But are people with poor eyesight going to care about the difference between an SVG rendered at 4x normal size and a bitmap at 4x? This isn't the most compelling argument for this technology.

Re:Expanding Complexity

[Anonymous Coward]

Next people will be making ice at home and watching movies with sound. Oh the mad rush towards tech....

OS X

[troc]

Doesn't Mac OS X already do this?

Troc

Re:OS X

[scrutty]

No, it has nice pretty icons and lots of scalable effects, but the icons are just scaleable pixmaps.

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

[amigaluvr]

OS X just has very large bitmap icons. 256x256 if you recall. I wonder what the processing difference really is between making a vector icon and between moving just a bitmap around and then hardware accelation?

Re:OS X

[neonstz]

I don't know about Mac OS X, but IRIX have had vector-icons for many years.

Re:OS X

[Anonymous Coward]

OS X does not support SVG in any way as is. Earlier on in the development of OS X SVG was supposed to be a core component of Quartz the way PDF is today. It can be assumed that timing issues were the reason for this change of plan.

Regarding icons, OS X uses PNG for icons. The way the Dock use them is that you have to provide your Application with a special .icns file that contain your icon in three (four? - can't remember) different formats from 16x16 and 128x128, then OS X computes the sizes in between. So OS X icons are scalable in that way, but it still uses a raster format.

-- junior

Re:OS X

[ActiveSX]

contain your icon in three (four? - can't remember) different formats

Four: 16x16, 32x32, 48x48, and 128x128.

great lib name

[RobertTaylor]

gdkpixbuf

That looks like someone headbutted the keyboard...

Re:great lib name

[FooBarWidget]

And why should you care? You are a user, not a developer. You shouldn't even have to know that it exists.

Re:great lib name

[sfraggle]

Hey, at least its a better name than libwnck

Re:great lib name

[Anonymous Coward]

Except when the various pieces of software on
your computer requires eight different versions
of that library.

Re:great lib name

[orcrist]

touchy much?

-chris

Re:great lib name

[FooBarWidget]

There are no 8 different versions of that library.

Re:great lib name

[Gerald]

Wait three months.

Re:great lib name

[Anonymous Coward]

Well, it's the obvious choice.

How else would you abbreviate "GNU's not UNIX Image Manipulation Program ToolKit DrawingKit Picture Element Buffer"?

Re:great lib name

[RossyB]

There has been two version of gdkpixbuf since GNOME 1. Finished trolling yet?

Re:great lib name

[yomegaman]

Wasn't that the villain that Superman had to trick into saying his name backwards to send him back to his own dimension?

Re:great lib name

[Anonymous Coward]

Makes perfect sense to me; doesn't it stand for GIMP Drawing Kit Picture Buffer or something?

Re:great lib name

[Anonvmous Coward]

"gdkpixbuf
That looks like someone headbutted the keyboard..."

He had his cat name it.

Re:great lib name

[The J Kid]

He followed this

He might just didn't get the joke.

Re:great lib name

[SPrintF]

"gdkpixbuf"

And if the developer says this backwards, he returns to the 5th dimension.

Mac OS X

[Fulkkari]

Those icons look really nice. But Mac OS X has already (at least partly) vector icons smoothly scalable from 16x16 to 128x128. They consists of 4 stages (16x16, 32x32, 48x48 and 128x128), and they work well in those ranges. I suppose it's theoretically possible to use even bigger icons in OS X.

Re:Mac OS X

[Anonymous Coward]

OSX has 'partly vector' icons, if by 'partly vector' you mean 'not vector in any way at all'

Re:Mac OS X

[Anonymous Coward]

Really? Since when? Last time I checked (10.2.3), it was just that .icns files contain bitmaps with multiple sizes. It is very far from being vector icons.

Re:Mac OS X

[Fulkkari]

I have to admit that my statement was wrong. I had tought that the Mac OS X icons were made of multiple PDFs (which can contain vector graphics), but obviously this isn't the case. I hadn't checked it myself. Sorry.

Re:Mac OS X

[Anonymous Coward]

To err human is; OSX contains PDF compositing engine that applications may (or may not) use. It doesn't mean that everything is composed from vectors.

On the other hand, the startup splash (with starting services progress bar) is saved as PDF. But it is one of few exceptions.

Re:Mac OS X

[demon]

Actually no, those are bitmaps. The largest icon size is 128x128 or something, but the icons are not vector based. (I had that mistaken impression before I actually used OS X - I could see the icon pixelation if I cranked up the dock size a bit.

I want this now!

[Anonymous Coward]

To all of you that sais "Come on, its only an ICON!"

Its not only an "icon" think vector graphics for scrollbars, menus, buttons, icons, backgrounds.. You can choose what every screen resolution you want and it will _still_ look good. If you are like me, I dont like the darn tiny icons I get when I blowup the resolution. I dont want it to go tiny! Why doesnt I run my screen in 640x480? couse I can see every pixel! Why doesnt I run my screen in 1280+ ? couse all icons becomes to small.. But in -1280 I do see the pixels.. And I dont want to, but I have no choice.. unless, they implement SVG on everything.. and SVG looks _great_

I just don't care!

[10Ghz]

Every time they demonstrate SVG-icons they do it by showing enormous icons that take up half of the screen real-estate. Guess what? I don't want my icons to be huge! I want them to be small and tidy. Apart for visually-impaired (read: half-blind), why do we need SVG-icons? Why would we want humungous icons cluttering our desktops?

Re:I just don't care!

[realnowhereman]

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".

Re:I just don't care!

[Anonymous Coward]

That is one good reason for having them. You want small icons, others might like big icons. With this you can chose whatever you want.

Just because SVG-icons are usually shown as large in screenshots doesn't mean they have to be large on your screen.

SVG is Good Stuff(tm).

Re:I just don't care!

[DarkBlack]

You are right, not all of us want large icons. However, the people drawing the icons want ones that scale without having to rerender the same icons at a larger or smaller size. It makes it easier for the artists and for the people who are visually impaired. It also should reduce diskspace for many icons.

If you don't care, that's fine, but since the GNOME developers have a desire to make their desktop accessible to everyone, which makes this important for them.

Re:I just don't care!

[Anonymous Coward]

Some displays have significantly higher resolutions than your average 72-96 ppi displays. To be usable on such displays, fonts and other user interface elements need to be scaled up. With vector graphics, you get sharper, potentially more detailed images. Nobody uses bitmap fonts anymore, and icons/widgets need to go the same route as fonts to make high resolution displays really usable.

Re:I just don't care!

[Sayjack]

Yes, but wouldn't it be nice to have more scaling choices than large/medium/small? There's more to SVG than just scaling graphics anyhow. Serialization is another goal of svg, hence you may be seeing the beginnings of webservices dedicated to serving up icons, animations, etc... XML and it's cooperative technologies are evolving rapidly.
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.

Re:I just don't care!

[Atzanteol]

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".

I couldn't have put it better myself. Have you noticed the massive influx of people with a "New technology? Bah!" attitude? Every time someone develops something new there's one idiot with a "My aunt Tilly doesn't use it, so I don't see how it could be of use for anybody." attitude.

I am not your aunt Tilly people!

Re:I just don't care!

[BigJimSlade]

Again, if you'll read some of the other posts, the large icons are not actually so large when you get up in the 1600x1200+ resolutions. When you start getting into huge resolutions like this, having scalable icons are really nice. You get the increased resolution, but your icons can visually stay the same size. Yes, you can do this with bitmapped graphics, but scaling vectors will be a lot smoother.

Re:I just don't care!

[10Ghz]

Well, I must admit that having icons stay at one size even though resolution changes _is_ a good thing. But the way this technology is demonstrated makes it look like that only thing this tech is good for is to make huge icons.

Re:I just don't care!

[doubleyewdee]

SVG is Good Stuff(tm).

How about "SVG's Very Good"?

Re:I just don't care!

[bwt]

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:I just don't care!

[iabervon]

Personally, I generally don't use icons; instead, I have the titles with no icon. It's just as easy to click and generally easier to identify.

But the real news is that there's now a SVG rendering library that's sufficiently compact and fast to use for rendering icons, which means that it's sufficiently mature and general to add to web browsers, which means that it's likely to become useable on the web. And the web does really need a graphics format which is resolution-independant, so that designers can let the graphics fit the text and window, rather than making the text and window fit the graphics.

Re:I just don't care!

[hysterion]

> It fills a necessary gap in the XML arsenal.

Thanks. Your post fills a much-needed gap in the discussion.

Re:I just don't care!

[Anonymous Coward]

I think that may have been too subtle for them.

Re:I just don't care!

[Anonymous Coward]

I am not your aunt Tilly people!

Why would you say such a spiteful thing, auntie? Don't you love me anymore?

Too late

[KhanReaper]

KDE has rendered SVG based icons since its 3.0 or 3.1 betas; this is nothing too new.

Re:Too late

[trtmrt]

Which iconsets use this under KDE? Do you need to turn SVG on somewhere in KDE? I use Carlitus' Noia iconsets which look great but they are not SVG.

Re:Too late

[protomala]

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.

Re:Too late

[tackat]

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.

Re:Too late

[Ur@eus]

Um, first of all librsvg has been in GNOME since GNOME 1.4, but this latest release of librsvg increases the amount of SVG it renders well immensly. In fact as you can see from the shot it render the SVG icons from the Crystal theme used in KDE perfectly. It does this using the actual SVG file.

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.

Re:Too late

[protomala]

Another reason told by KDE developers, is that the KDE svg support wasn't complete (no scripts and some options) so they didn't wanted to release something incomplete, in what I agree 100%.

Re:Too late

[Anonymous Coward]

uhm, takcat _is_ the main kde developer for icons for a long time.

Once again... /.'ers rally against the cause...

[Anonymous Coward]

Jeeeze, just reading a few of the first posts on here you'd think that SVG icons were the end of the world. Nothing could be farther from the truth...

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...

[IamTheRealMike]

One of the big reasons I like OSX (and I do not own a Mac, FYI) are the scalable vector icons

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...

[Textbook Error]

It uses scalable bitmaps, which is nice, but they can't go any bigger than 256x256

They're 128x128 actually.

Re:Once again... /.'ers rally against the cause...

[nomadicGeek]

Here's the algorith.

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.

Re:Once again... /.'ers rally against the cause...

[abe ferlman]

nice, but they can't go any bigger than 256x256

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...

[thatguywhoiam]

(on 'the cause' - no kidding, eh?)

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...

[oever]

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.

More exposure for SVG is good too. I hope we'll have good SVG support for webpages soon. Scalable images in webpages is something badly needed for a long time. SVG is not a perfect standard for scalable, but it's a first step.

Re:Once again... /.'ers rally against the cause...

[styrotech]

More exposure for SVG is good too. I hope we'll have good SVG support for webpages soon. Scalable images in webpages is something badly needed for a long time. SVG is not a perfect standard for scalable, but it's a first step.

I agree with you totally, but fear that you are too optimistic. IE can't even do PNG alpha transperancy yet, I'd hate to think how long it would take for native SVG support in IE.

And yes, I know the Acrobat plugin also bundles Adobe's SVG plugin these days, but how many web designers or users have even heard of SVG?

I hope I'm wrong though :)

Re:Once again... /.'ers rally against the cause...

[metamatic]

Bzzt, wrong yourself. The dock uses scalable vector icon images in PDF files for things like the "poof" cloud.

Re:Once again... /.'ers rally against the cause...

[psamuels]

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.

You're describing a 1995 technique commonly known as "tooltips". Most modern graphics toolkits support them - maybe yours doesn't. Basically a small text box pops up under or beside an icon when you hover over it, and disappears when you move away.

The problem with using tooltips to convey extensive information is that the box obscures everything underneath it, so if you mouse over something without needing the extra information it just gets in the way and you find yourself probing around for a non-hot-spot. This is particularly heinous when the app designer starts "activating" the UI elements within your work area. For example, a CAD program I used to use pops up a many-line tooltip whenever you hover over a point, line, circle, etc., giving its whole curriculum vitae. Thankfully you can turn this horrible behavior off.

I suppose tooltips as a way of giving extended information (as opposed to giving a "hint" about what the icon does) could be useful if the pop-up box had a semi-transparent background or something. This ought to be possible in NT5, whose GDI supports background alpha, but I don't use Windows enough to know if it is implemented.

A better way to clone the OSX look and feel?

[image]

Right after OSX came out, I remember downloading a GTK and Gnome theme for my Linux box that copied the look, if not feel, of OSX. If I recall correctly, that theme was yanked by Apple's lawyers.

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?

[Anonymous Coward]

As OSX icons aren't SVG in the first place... you could skip the whole step with needing to run SVG on your linuxbox to copy the look.

OSX icons are just 128x128 and very nicely drawn

Re:A better way to clone the OSX look and feel?

[GauteL]

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.

Re:A better way to clone the OSX look and feel?

[image]

> 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".

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.)

Re:A better way to clone the OSX look and feel?

[Anonymous Coward]

Another bit of kudos to apple is that in their UI guidelines, the concept of high-quality photorealistic (but not photographic) icons is stressed. That's something that really puts a crystal clear look to a desktop.

It's quite similar to what's done with photographs on the covers of magazines, especially the glossier fashion rags. That's been one of my jobs over the years and there is almost nothing that hasn't been touched up in most model photos. Generally just slight changes, but enough to make an unrealistic-photo look better than the original.

It's all a kind of marketing really, but if it makes for a really nice crisp desktop that's a joy to use, I'm all for it!

Re:A better way to clone the OSX look and feel?

[smallduck]

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".

Totally correct in the part about the SVG and the scaling and the magic. But hey, resources aren't just for resource forks anymore! The file format of resource forks live on in (the "data fork" of) .rsrc files. But in many cases, resource files are obsolete, replaced by many files loose within bundles. Loose, hell, willy-nilly even!

Indeed, in the case with icon files, Apple defined a new icon format circa OS 9 or so containing old school bitmaps of various sizes/depths plus masks, and also 64x64 & 128x128 pixmaps with alpha channel. This format works in 'icns' resources and also within .icns files. In OS X, the latter is more common.

My work is done here.

the end of diferences?

[protomala]

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. :)

Finally, great news for users :)

[CheeseCow]

This is excellent news. After getting a new monitor that does 1600x1200, I found those tiny icons a bit hard to click at times. But now, I can run whatever resolution I want, and the icons will just look better & better.

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! :D

Re:Finally, great news for users :)

[DrSkwid]

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.

Re:Finally, great news for users :)

[tempfile]

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.

KDE does this already

[Anonymous Coward]

KDE does this already with its crystal-svg theme.

Mindblowing

[CoderByBirth]

I really think that scaleable icons are gonna be THE killer application of tomorrows operating systems.

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.

Re:Mindblowing

[Anonymous Coward]

Personally I find the concept of requiring graphics on a desktop for more than drawing demarcations between areas wasteful.

Skip icons. use text. I can read dammit, and don't have to re-interpret some artfartists idea of what that text should represent graphically.

Re:Mindblowing

[jimmy_dean]

Not everyone can read though. And you may argue that perhaps people who cannot read should not be using a computer. Maybe so...but what about the visually impaired? Icons are a lot more visible than smaller text. And one couldn't miss a spinning icon or the like.

Re:Mindblowing

[jorleif]

Spinning folder icon? Shudder, we hates everything that moves without a reason, reminds us of nassty Clippy. Seriously though the information communicated by icons could be increased. The changing mailbox icon for "You've got mail" is familiar to all of us, but there could be lots of other uses. For instance download dialogs could minimize to icons and change color depending of their degree of completeness (a complete download glows of translucent green). The taskbar items of programs could turn more red when the program is using lots of CPU and so on.

Re:Mindblowing

[sean23007]

And then imagine Microsoft implementing them and allowing a website to change your settings through Internet Explorer. You close your browser and you notice with dismay that all your icons are spinning, bouncing, and dancing. Doh...

Re:Mindblowing

[RustyTaco]

For instance download dialogs could minimize to icons and change color depending of their degree of completeness (a complete download glows of translucent green).

Since nobody else seems to have mentioned it I will. IE 5 on MacOS9 used to do this. When you download something the file would imediatly appear (no hiding off in some mystical temp space) as a partial download. The icon would have a vertical "thermometer" that would bet filled as the file downloaded. It was actually pretty useful, and I'm kinda sad to see it doesn't appear to have survived into OSX.

No "download manager" window, or even a dialog box. Just the file with it's status on it. Of course, with live SVG icons you should be able to make it pop-up with more details than a rough percentage on command. Hmm, yummy.

- RustyTaco

Re:Mindblowing

[psamuels]

Not everyone can read though. And you may argue that perhaps people who cannot read should not be using a computer.

Yes.

but what about the visually impaired? Icons are a lot more visible than smaller text.

Ah, but what else is a lot more visible than smaller text? ... wait for it ... larger text!

And one couldn't miss a spinning icon or the like.

That's the whole point. We don't want to be bombarded with information we don't care about. It's distracting. So unless you think the UI designers will have an exact phase match with me with regards to my priorities of what I want to think about at any given moment, what is important enough to interrupt my train of thought and what isn't, then keep your animated ads^Wicons off my desktop.

Sheesh, next you're gonna give my icons access to my sound card. *shudders*

Corresponding Browser support?

[brianjcain]

So can we expect similar native SVG support from our favorite gratis and libre browsers (Mozilla, Opera, et al) soon? I think it's only been available via a plugin before.

Re:Corresponding Browser support?

[KjetilK]

I'd be interested in hearing about progress too.

You have the Mozilla SVG page, but it has not been updated in a while. I heard they had some licensing problems....?

Then, there's a message at from Sue Sims who I think works at Opera, she says it is scheduled for the next version. This was in May, and that would imply version 7, I think, but it doesn't seem to be in there.

Re:Corresponding Browser support?

[Turmio]

Adobe has offered SVG plugin for Mozilla-compatible browsers (and IE) since 11/2001. Get it here: http://www.adobe.com/svg/viewer/install/main.html. It's not libre, but gratis and does the job. There's version for Linux, Windows, Mac OS X and obsolete Mac OS.

Re:Corresponding Browser support?

[pacc]

Adobe's SVG viewer has been incompatible to mozilla since version 1.0. They obviously used an unfroozen API and haven't come up with a new version since.

Though it still works nice with IE ;)

Svg Developpement

[Sepper]

Nice to see progress being made in this direction...

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 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. 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...

Re:Svg Developpement

[mbbac]

My biggest problem with SVG icons is that I haven't seen any with detail approaching the 128x128 icons that are used in Mac OS X. I'm not sure if it is just hard for people to create, or if it is an inherent limitation of the medium.

I suspect it is a limitation of the medium, but I would love to be proven wrong. Otherwise, I think Apple has the best solution.

Re:Svg Developpement

[Cid Highwind]

I doubt it's a limitation of the format. My guess its that the difference has more to do with how much money Apple is willing to throw at graphic artists to get those great icons.

Re:Svg Developpement

[mbbac]

How do you use that to explain away the very striking icons that third-party developers use for their applications?

I think it is a limitation of using vectors solely. I think that either getting the enormous detail you can get for free from a bitmap is either (a) not possible with strict vector images or (b) too expensive to render.

Fat Icons BIG business

[oliverthered]

Comeon, havn't you seem KDE3.1 or Gnome Or OS X , Nice big fat ICONS with frilly bits on the side, even though there an inch and a half square you still can't work out what there ment to represent.

Think I'm joking?
KDE 3.1
Gnome
Mac OS X (couldn't find non-quicktime screen shorts!

ohh and this mac[dot]com possibly the worst designed website in the world.... Nothing's hot so you have to move the mouse randomly around the screen looking for an address poping up in the status bar....
Backup == Umbrella?
Well done, top marks.

Re:Fat Icons BIG business

[rseuhs]

Comeon, havn't you seem KDE3.1 or Gnome Or OS X , Nice big fat ICONS with frilly bits on the side, even though there an inch and a half square you still can't work out what there ment to represent.

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:Fat Icons BIG business

[oliverthered]

Hey, I only run Linux at home,
but there is a growing trend to even less understandable, far to pretty icons. I havn't seen what XP looks like, don't really care either.

This is a nice tactile desktop though.

Re:Fat Icons BIG business

[Anonvmous Coward]

"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"

So, by your argument, a VW icon wouldn't mean car? I'd go into detail, but first I need to know if you understand the concept of what a logo is.

Re:Fat Icons BIG business

[NanoGator]

"Sometimes I really start to think that the rumours about Microsoft paing people to post on various forum sites are true."

Yeah, paying people to preach to a bunch of MS haters would be so fruitful. It couldn't possibly be that less bigoted people can see that MS did some stuff right. Here, I'll prove my point:

"Yeah, I know, absolutely *nothing* can beat a blue "e" in intuitivity."

What makes it intuitive is the words "Internet Explorer" right next to (or underneath) the icon. The nice thing about the blue 'e' is that it scales down to like 32 by 32 and is still readable.

If you think designing icons is easy, why don't you try making an 'internet' icon that's readable at 32 by 32.

nice, but

[CaptnMArk]

makes me wonder why is libpng so slow?

Were the svg icons compressed (gzip)?

Re:nice, but

[Ur@eus]

no, librsvg supports .svgz files by using the libgsf
library. This library is not part of the GNOME 2.2 release however (will be included for 2.4) so the .svgz support is not being used for the current themes.

About scalability

[Anonymous Coward]

The thing about scaleability of vector graphics (including SVG) is that the scaling works great if your are making the graphic bigger. However, if you want to make the graphic smaller you could have trouble. The problem is when you start to get to a small size the stroke thickness of the vectors cease to scale at some point thus distorting the intent of the graphic artist who designed it. For example, say you had a square with a black line that was 20px x 20px and the stroke of the line was 1 pt. If you cut the size in half to 10px the stroke should scale to .5pt (roughly half a pixel). So the problem becomes, how do you render half a pixel? You anti-alias it that's how. Unfortunately this would lead to 'blurry' looking little icons and mine eyes are sore as it is! ;)

I'm not saying that SVG is bad just that the scalability is not never ending and for small icons this may not be a good choice. It is also not likey SVG could allow you to 'design one l33t icon for all resolutions!' because of these issues.

How can they say it's faster?

[3770]

If I make an SVG icon with 2 billion vectors, will that still be rendered faster than a .png icon?

If it still is faster it means that they are drawing it once to a bitmap buffer that they use from then on, but that can be used for .png also.

I say, mod the article itself as clueless.

Re:How can they say it's faster?

[FooBarWidget]

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.

Re:How can they say it's faster?

[Ur@eus]

This was made in reference to the free SVG icons out there which is also availabe in png format. What the rendering speeds are for the extreme cases it not really interesting.

Re:How can they say it's faster?

[0x0d0a]

Frankly, I'm a bit surprised that they can find *any* SVG (particularly if it's antialiased) icons that render faster than PNG icons. It seems like vector rendering would take far more overhead.

Re:How can they say it's faster?

[Anonymous Coward]

Don't be stupid.

Of cource it would be slower, but then what if you made a png icon that was 10000x10000 px and compared it against an SVG icon that was just an outline of a box with black lines?

Use your head moron.

Re:How can they say it's faster?

[Anonymous Coward]

A lot of time, the bottleneck is at the IO layer. For example, if your icon is a circle with a gradient. This is a couple of lines in SVG which can be gzipped for even smaller footprint. Now png can be compressed but the file size is still a lot bigger then the svg file. The SVG icon can be rendered before PNG is loaded on a slow HD...

Re:How can they say it's faster?

[StressedEd]

If the rendering engine is generally being asked for a set of icon sizes (e.g. 16x16 32x32 etc.) it can cache ones that exceed some form of rendering time criterion as as (insert bitmap format of choice).

That way complex icons with "2 million vectors" need only take the same length of time displaying a bitmap. Simplistic and potentially a hard disk / virtual memory filler I know, but I expect it would work well for icons, which are generally a set of sizes.

Re:How can they say it's faster?

[Nicopa]

2.000.000.000.000 vectors?

That would put one vector per pixel in my 1142857142857x857142857142 monitor.

Good news, but it would be much better...

[ubiquitin]

...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.

Re:Good news, but it would be much better...

[PigleT]

" a really good SVG editing tool."

Have you tried sodipodi?

Re:Good news, but it would be much better...

[Queuetue]

Isn't NeXT's display postscript being used in Aqua?

Re:Good news, but it would be much better...

[WillAdams]

Well, NeXTstep survives as Mac OS X....

You're also leaving out Go's PenPoint which had resolution-indepent UI as a designed-in concept.

Moreover, that these OSs (incl. SGI's) failed is not a function of the (alleged) unimportance of resolution independence (which really, only Go implemented), but other forces.

Ironically, Windows has actually had a mechanism for setting logical display dpi for a long while, but it's seldom used 'cause icons don't scale and get too small, and far too many Windows apps are Mac ports w/ hard-wired 72dpi screen settings :( That said, when one does set it up, it can be well worth the trade-off of smaller icon sizes to have larger, sharper text w/o zooming and which approximates 100% size on-screen.

William
(who used to have a post-it note on his display at another job, ``167% == 100%'' so that he could set that display setting, hold up a print-out against the screen and compare directly)

Re:Good news, but it would be much better...

[Anonymous Coward]

What do you mean, "worth noting that NeXT had display Postscript robustly implemented... but [isn't] around today?" Have you ever heard of Mac OS X? GNUstep? The former is a direct descendant of NeXT, and incorporates the next generation after Display Postscript, Display PDF. GNUstep is following in NeXT's shoes by using the excellent GhostScript Free Software Postscript engine for its vector rendering backend. There's nothing "dead" about this kind of innovation; people who give these desktops a try generally become avid fans and even rabid evangelists for the cause.

Re:Good news, but it would be much better...

[t_hunger]

Just because vector-based GUIs were no good 25 years ago does not mean they will suck now. In fact I'm convinced moving from pixel-based to vector-based is a necessary step that will need to happen in the free software world soon. The mayor commercial companies either have allready taken this step (Apple) or are preparing to do so in the next release of their environment (Microsoft).

During the last 25 years there were only rather simple graphic cards. Today, with people putting 500MHz, 128MiB graphic boards (that's more graphic memory then my first PC's harddisc had and 20x the clock speed!) into their computers, staying in the pixelworld is just a terrible waste of resources. There's not too much you can do to speed up pixel-based rendering, most that could be done was allready handled by those "Window accelerator boards" in fashion a couple of years back.

Having said this I don't consider those historic vector-based systems a failure either: Most are much more thought out then their more hackish pixel-based counterparts that were on the market at the same time. Technology had not stopped them, they were killed mostly by other decisions: NeXT introduced a new language for their system for example, stopping many developers from contributiong (at least till they had learned the ObjectiveC extensions to the vanilla C). Then hardly any of those environments was cross-plattform, so there was little incentitive for companies to write software for those systems. Finally there was no free implementation so there wasen't much free software written.

PS: I really find the inovation cycle in free software so depressiong:

Apple turns a great idea that has been around for a while into a product.

The (free software|open source) community ignores it.

Microsoft copies the idea from Apple

The community argues that the whole thing is eye-candy und ruins productivity

Some wierdo hacks together yet another extension to X (be it a 'real extension', a windowmanager or whatever), bringing that feature in some limited but cool looking way to the community.

The community claims the new feature is god-send and makes Linux ready for the desktop.

Some other project decides to write a free replacement of the Microsoft-tool which at some point becomes useful and maybe even better then the original.

Everybody (in the community) agrees that the free software model is so much better because it was able to copy the original thing in hardly no time doing minor improvements along the way.

That's so sad :-(This happened with things like graphical configuration tools and filemanagers to name just two, it will happen with vector-based GUI environments. We should be able to do better then this! Sorry, I'm a bit depressed today... please excuse my negative tendencies:-|

Re:Yeah, but...

[Anonymous Coward]

I know I'm beating a dead horse, but it bothers the hell out of me.

Will it do anything to fix that godawful file selector box in Gnome? No? Then work on that first.

Thank you. I'll be here all week.

Bothered? There's work for you.
First, get the latest sources from CVS to see whether the selector box matches your expectations or not. Sorry, but complaints about GTK+ 1.2 and its wrinkles are considered outdated these days.
Second, get off your demanding ass and fix the problem as you see fit.

This is a pure troll

[GauteL]

And an incorrect one at that. Nautilus has supported SVG since GNOME 1.4, and KDE 3.1 STILL does not support SVG. It is however on the plan for KDE 3.2. Now GNOME will support SVG in all areas of the desktop.

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.

One quick question

[IamTheRealMike]

How does librsvg compare to ksvg? Which is faster, more compliant, more powerful etc?

Re:One quick question

[tjansen]

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.

Re:One quick question

[Anonymous Coward]

faster->librsvg
compliant->librsvg
powerful->ksv g

Ksvg is currently where librsvg was several months ago. Since then, we've put in a lot of bugfixes and optimizations in librsvg (before the GNOME 2.2 release).

Ksvg, to it's credit, it the more ambitious project. I think the KDE developers will probably have it fully compliant and a bit faster once KDE 3.2 comes out.

Anyway, it's good for the general community, as SVGs become predominant in both desktops.

Re:One quick question

[Anonymous Coward]

Indeed the two are different beasts. Ksvg tries to be a dynamic svg viewer, librsvg seems to be a static svg viewer. Currently ksvg is a bit messy, we'll try to get it in better shape though.

Rob.

And GNOME significantly predates that

[0x0d0a]

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.

Re:And GNOME significantly predates that

[tackat]

just nitpicking: I'm not aware of Gnome having used SVG icons desktop wide - except for one application in gnome (a filemanager) which was able to use SVGs up to a certain point ;-)

So as far as I know KDE (read: K Desktop _Environment_) was the first free desktop environment which used SVGs in the whole environment.

Re:And GNOME significantly predates that

[Ur@eus]

If you are refering to using SVG icons all over the environment converted to png files, GNOME did that with the Gorilla theme.

Re:And GNOME significantly predates that

[tackat]

No I'm referring to using them all over the environment in realtime _without_ conversion. Conversion to png was just done because we decided that we couldn't test all possible cases within 4-6 weeks.

Mozilla

[Anonymous Coward]

Mozilla has a native SVG project that's been around for awhile.

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

[IamTheRealMike]

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?

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.

Re:Mozilla

[po8]

For those who aren't aware, Carl Worth and Keith Packard's Xr library (the link is pretty stale, sorry) works with the X Render extension to provide a really nice 2D rendering model. They've done some cutting-edge work here, including high-quality anti-aliased compositing, high-speed rendering, high-quality splines, and a Postscript-like C API. Postscript/PDF and SVG support is an explicit goal of Xr: xpdf has already been modified to render with Xr (and Xft), and it looks great!

Watch for an upcoming announcement soon, when the project is sufficiently complete.

Re:Mozilla

[Nicopa]

The problem as I understand it is that the SVG library Mozilla currently uses has a license that's incompatible with the Mozilla license.

A bit inaccurate. The library in question (libart) is LGPL and it's perfectly compatible with the MPL, GPL, etc. The thing is that it's mozilla.org's policy not accepting LGPL code.

SVG trade-off ..

[bockman]

... is that it swaps memory for CPU : SVG images (and in general vector-bassed images ) require less memory to be stored, but more CPU to be recreated.
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 ..

[arkanes]

I was wondering about the speed thing too - it's hard to get faster than blitting a bitmap onto the screen, especially since modern graphics hardware has umpty-jillion hardware optimizations.

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 ..

[Knobby]

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..

Re:SVG trade-off ..

[dominator]

RSVG doesn't render to a PNG, it renders to a RGBA buffer. GdkPixbuf then blits the RGBA buffer to the screen/XServer/whatever.

In a lot of cases, it's faster to use something like libart to generate the RGBA buffer from a SVG description than it is to decompress a PNG to its RGBA contents. In some cases, it is not. What's faster depends a lot on your CPU, RAM, bus, and the particular image(s) involved.

Cheers,
Dom

Terrible Screenshot

[1000101]

I clicked on the screenshot they have on the website and, to me anyway, it looks terrible. The fonts are bad, and even the graphics need alot of work.

Re:Terrible Screenshot

[Ur@eus]

Well new improved fonts are on the way from Bitstream after their recent agreement with the GNOME Foundation. As for the graphics in the theme, I assume you refer to the gtk theme used. I am aware that there are some issues with it (and I have already received some fixes for it), but I did not want to put to much effort into it as it is meant to be replaced in a later version with a SVG based GTK theme (with the same general look however).

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:Terrible Screenshot

[Anonymous Coward]

Maybe you have ie6 and forgot to enlarge the image to its actual size. That could make the image appear quite ugly.

Just a thought.

Re:Terrible Screenshot

[fault0]

I'm not sure why they chose to use both Sphere and Crystal. Both are very good bythemselves, but mixed together like that, it looks bad.

And there should be a bit more spacing in the titlebar :)

Try Sodipodi

[Ur@eus]

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.

Re:Try Sodipodi

[WWWWolf]

Sodipodi has consistently not impressed me. It has great potential and the implementor folks are sure making it better, but it doesn't work yet, especially in regards to SVG. Which is, of course, completely confusing.

If I make a nice-looking SVG file in it (if it somehow actually works), Nautilus shows it wrong. If I make a nice-looking SVG file in Sketch, and open it in Sodipodi, Sodipodi shows it wrong. Or crashes.

It's sad that Sketch is still the best vector graphics program for Linux - it's not bad, and it sort of works, but the UI isn't the best possible... =/ I really hope this library thing will make things better!

ooooh, shiny!

[Anonymous Coward]

Scalable icons! Just like in OS X!

I bet you don't have an OS X box, though. Maybe it's too expensive, maybe you hate MACs [sic], maybe blah blah blah. Obviously scalable icons aren't the killer app of "tomorrow operating system;" otherwise you'd be running OS X already.

Next question.

Can Mozilla use this

[m0RpHeus]

I know Mozilla has a native SVG-renderer. However, it seems that it's not moving fast and it seems that it won't be included anytime soon because of licensing isues (they're using a modified version of libart. I know it's LGPL'ed but it seems that in order for it to be included, it must be re-licensed to both GPL and MPL.

Maybe Mozilla can use this renderer instead. It would be cool that SVG would be more dominant than flash when it comes to vector images.

Just a thought anyway.

Re:Can Mozilla use this

[Jack William Bell]

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.

Re:Can Mozilla use this

[Ur@eus]

Yes and no. There will probably be made a Mozilla plugin using librsvg for displaying SVG images in Mozilla. But long term Mozilla needs an integrated SVG viewer which use their rendering model to be able to have advanced SVG manipulation functionality beyong just viewing images.

try running @ quad XGA with 48 pixel icons

[DrSkwid]

run your desktop at 2048x1536 and you'll get a harsh lesson in how poor the computing world deals with different resolutions.

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 .. Text Zoom] on mozilla & [View ... Text Size] on I.E.

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:try running @ quad XGA with 48 pixel icons

[tempfile]

That's why you have to increase the rendering resolution using the -dpi argument of X. A 12pt font on a 200 ppi display rendered for 100 ppi will appear only 6pt tall.

Re:try running @ quad XGA with 48 pixel icons

[Anonymous Coward]

Opera is the only browser that correctly addresses zoom. It zooms everything (including images) so that it looks the same no matter what zoom level. You can set what zoom level the browser starts at. Though I have noticed sometimes frames stay in the same place, but this may have been an older version.

Hardware support for SVG

[Anonymous Coward]

I'm wondering when we will see hardware support in videocards for SVG? I guess modern day GPU's should be able to handle the vectors used in this format... This way we can really see some nice speedups in the rendering of vector art.

Re:Yeah, but...

[0x0d0a]

You mean the one that some GNOME 1 distros used, where clicking on a folder cleared the filename, a la Navigator?

GNOME 2's already eliminated that.

When you get small

[oliverthered]

Things get funny when you start to use small Icons. Just look at the way fonts render with freetype or AA switched on. There just SVG's with a different name.

'half-blind'

[Big Sean O]

Funny how you mention half-blind.

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).

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:'half-blind'

[hysterion]

> --
> Patriots don't drive SUVs [salon.com]

Scalable Utility Vehicles? Now that would be nice. From pickup in redneck country to italian cabrio on Route 1, to big white limo as you enter NYC. Yum!

What's going on?

[Tyreth]

Why are there so many people complaining about "what's the point of SVG" or "what a waste of time" kind of arguments. What's the issue here?

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:

• Prettyness - this is the most obvious. Most people like something that looks good! Sure, it may not have an obvious practical advantage, but humans are naturally attracted to things that look good, as opposed to a website with black background, red/yellow flashing text with images with white backgrounds. There may be something deeper to this - when something looks professional /pretty, it feels easier to understand. The less attractive it is, the more complex it feels. Quite simply, the more something feels like sphagetti the less our mind will be able to comprehend it and move on to newer things. The neater something is and the more we comprehend it, the easier we will find to move on to something new.
• Resolution - been mentioned earlier. Different resolutions require different font sizes. This means that the artist can make an icon that will be useful from now until the time computers go primarily 3d. They don't need to anticipate resolutions of the future, their work will scale seamlessly.
• Speed - this is a speed improvement. The more our code is improved and sped up, the more integrated it can be. This is just one of many enhancements to Linux that make community software that bit better.

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.

Re:What's going on?

[number6]

> What's the state of SVG in KDE?

Installed 3.1 partly to try out the SVG support. Apparently there's been an SVG theme for KDE 3.1 for a while. It also works in Konqueror, though only seems to support SVG in files with a .svg extension. If I create an html file, and stick some svg in it (with namespaces etc set, basically the example from the back of the book 'SVG Essentials'), Konqueror doesn't render it.

Seen the same problem with IE.

Haven't got around to compiling Mozilla with it in yet.

A just as important question - when will Mozilla have SVG support in the base build? Currently there seem to be license issues (the library it uses can't be licensed under the MPL). I'd say getting Mozilla, Konqueror and Safari all supporting SVG as standard is an important step.

It's been at least 5 years since I displayed vector graphics in !Browse after all (I wonder whether anyone gets *that* reference) :-)

Re:What's going on?

[Anonymous Coward]

Actually your point is more prevalent in the discussion than the position you're criticizing (browsing at +1).

Why would people be critical of svg? Because they haven't seen the benefits of it, and it sounds like yet another bit of geewhiz that will distract developers from doing what needs to be done.

Case in point, people want to see examples of svg in action. They are pointed to pages that require a plugin from Adobe which apparently won't work with current versions of Mozilla, and was only tested with Redhat 7.1. Okay. Somebody points to mozilla's svg project and there are examples there, if you have the svg module whatsit installed. Is it worth the hassle? I can't say. The examples don't quite work for me and I don't know why. End Result: frustration with package management and tbe limitations of Free Software. It sounds like a great idea, but the implementations suck.

Now, you talk about svg in desktop environments like Gnome and KDE as a replacement for pngs and how wonderful that will be. Excuse me but Gnome has been a woeful state of flux recently and pretty icons are the least of its problems. KDE 3.1 sure looks nice, if only I could figure out why font selection dialogues crash my x. Personally, I'm not turned away by stuff like that, but don't be surprised if you get some flack.

You argue svg won't mean more bugs, but since when has that been true? More libraries, more dependency hell, more inconsistencies, more confusion. Anybody proposing radical innovations in popular programs like Gnome and KDE ought to be able to defend it. If this were about an independent svg desktop project, then people wouldn't be so touchy and would be more readily led by their curiousity and their wonder.

Answer your question?

Deformable matching for scalable graphics

[more]

It is nice to have the sharp features aligned with the pixel boundaries while still maintaining approximately the geometric relations. Perhaps a deformable match of the high frequency features with the pixel boundaries could be a solution for showing glyphs most accurately on pixelized displays?

Deformable matches are used in advanced medical applications between 3d volumetric images: CT, MRI, PET, etc.

Re:Deformable matching for scalable graphics

[Spy Hunter]

Freetype's font auto-hinter does this. So if you're using anti-aliased fonts on XFree86, you are seeing this idea in action (unless you're using the truetype font hints in violation of Apple's patents, but they do much the same thing anyway). I don't know if any SVG implementation does this yet.

Excellent...

[Anonymous Coward]

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 :)

Re:Excellent...

[GlassHeart]

The whole point about SVG is that they will render nicely whatever the screen size. This isn't only relevant for big screens.

Uh, no. There is no reliable way to shrink an image below a certain minimum scale - bitmap or vector. When two distinct features are shrunk into a single pixel, bad things happen. This is why OS X allows a developer to specify alternative small icons. This is also why font antialiasing is usually disabled for text smaller than a certain size, because they just become blurred. Even for larger sizes, extensive hinting is required for some glyphs to look sharp.

Not to say this isn't good progress. Just that an icon designed to be 128x128 or so probably still has to be redrawn for a 320x240 screen.

Display SVG

[DrXym]

Screw the icons, how about a complete display SVG engine akin to Display Postscript / Aqua?

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.

Icon scaling != usability

[HelbaSluice]

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.

Re:Icon scaling != usability

[entrigant]

Disclaimer: IANAVGKIAG (I am not a vector graphics know it all guy)

But... seems to me any decently evolved vector graphics technology would do exactly what you are suggesting. How much do you know about SVG anyways (and if you don't know much about it why are you commenting on it like this)?

SVG for fonts.

[Anonymous Coward]

I've often wondered why we dont see any SVG font offerings, since fonts are even part of the SVG spec I believe. Using SVG fonts would remove the issue of patents surrounding TTF (which is basically the standard font format). Now Xft/Xft2 could still support TTF fonts and such, but they could also load SVG fonts. All the OSS/FS community would need, is someone to make the fonts. :)

Re:SVG for fonts.

[psamuels]

Using SVG fonts would remove the issue of patents surrounding TTF (which is basically the standard font format).

Maybe, maybe not. Certain useful techniques for encoding and rendering fonts are covered by patents - but it would take a more knowledgeable head than mine to say whether or not those would affect font encoding and rendering in SVG.

Anyway, if you want scalable, hinted fonts and are afraid of TrueType, you should be[*] using Type 1, a spec borrowed from Adobe Postscript. Type 1 fonts may or may not be under the shadow of the TrueType patents, but they fit your requirements every bit as well as SVG fonts.

[*] By "should be", of course, I mean "probably already are". Your X server has been rendering Type 1 fonts since about 1993.

Session Migration

[msobkow]

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:Session Migration

[m94mni]

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.

Not so far away...

I'm having this problem every time I use my laptop to do presentations. As it's 1600x1200 and most projectors only support at most 1200x960, my desktop layout is screwed up every time!

Note that this is not yet a problem in Linux... I'm still waiting for the RANDR X extension to enable this kind of problem :-)

Re:Session Migration

[edwdig]

Perhaps rather than storing icon positions as exact pixel coordinates, a better solution would be to use the approach GEOS file managers used - store the icon position as the percentage away from the nearest edge of the screen. That way, when you changed resolutions, the icons would still be more or less in the same position. If you had a crowded desktop and shrunk the resolution, then yeah, you'd get icons overlapping, but otherwise things worked out pretty well.

Re:Session Migration

[doorbot.com]

I'm surprised no one has mentioned a key benefit of SVG desktops: session migration.

So, would it be possible to transmit the icon itself as text (XML) and then let the remote X client render it as it chooses? Seems like that would be faster than the server rendering it and then sending the pixmap...

Re:Session Migration

[msobkow]

With a thin client I'd presume the X session (or GDI, or whatever) is running entirely on the client. As SVG is already using XML format, it's almost ideally suited as a format for downloading the icons to the thin client, where it is rendered locally (as you suggested.)

gdkpixbuf

[siphoncolder]

"gdkpixbuf"
"librsvg"

Say that twice fast.

Scalable Grammar

[Anonymous Coward]

"Not only do it render them,"

Seems to me he needs to worry agaout scaling up his grammar...

Patent issues all resolved? It _appears_ so...

[dwheeler]

At one time, I recall that there were some serious patent issues with SVG. Basically, SVG wasn't really an open standard, because it was patent royalty encumbered - giving an automatic disadvantage to those who weren't patent holders, making it impossible to implement using open source software / free software, and discouraging implementation in any place where expenses have to be kept down (including some small businesses and mass market devices).

According to http://www.w3.org/2001/07/SVG10-IPR-statements.htm l and http://www.w3.org/Graphics/SVG/Disclosures, 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.

Re:Patent issues all resolved? It _appears_ so...

[Anonymous Coward]

I've heard otherwise. The statements you quote are old and SVG has grown to do more things which some people think they invented (don't tell Tom Duff!) Time will tell.

LGPL is already compatible

[msobkow]

LGPL is compatible with both GPL and MPL software, you are just required to leave the LGPL code in a shared library or DLL rather than embedding it in the application.

The only people who'd want to move it over to MPL would be those who want to embrace and extend from a corporate perspective. SVG is simple and small enough that the few surviving corporates who need to implement such a library can do so with relatively few resources if they aren't willing to live with the LGPL requirements.

Re:Too bad about the LGPL

[Anonymous Coward]

The point being, that the license of your own SVG library will be under a stricter license(closed source even?) and give the user less freedom than if you had used librsvg, had been under BSDL and thus opensource?
Can't argue with that. However, you have to understand that GPL and LGPL are not about freedom! They are about Free Software and have no relation to freedom at all. It's a software license intended to kill all other software, because to Richard there should only be GPL software.

Informative indeed.

[vadim_t]

Maybe try to read your parent comment? I quote:
killustrator, sodipodi and similar apps just aren't ready for prime time

Dependency hell

[marmoset]

This is cool and all, but is anyone else shuddering at the idea of a Gnome build with even more library dependencies than it has now? Screw getting a cup of coffee while Gnome builds, it's more like grow your own beans, roast them, age them, grind them...

Linux Vector Tools

[Sludge]

Hmm.. What do people use to develop the SVG icons? I can think of a few obvious anwsers from powerful graphics packages, but I though they were all stuck in win32 land. I'd like to know of something for Linux.

Re:Linux Vector Tools

[tackat]

Crystal SVG was developed using Adobe Illustrator 9.

Re:Linux Vector Tools

[1010011010]

Sodipodi -- it's a gnome app. I've developed some SVG drawings using it, and it does okay.

Comparison of SVG and display PDF?

[sir99]

Scaled icons would be sweet. A nice step towards resolution independence. But how does SVG compare with other vector drawing systems, like display PDF? What are advantages and disadvantages of each?

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. :-)

Re:Comparison of SVG and display PDF?

[rfmobile]

Ghostscript is

• (1) slow, slow, slow.
• (2) can't support multiple documents

#2 is due to use of C-style static variables.

Compare GSView and Adobe's own Acrobat reader and you'll see why ghostscript is problematic for snappy, repsonsive interactive use.

The best demo i found.

[Jeedo]

Adobe has made some nice Demos of the capabilities of SVG especially things that would previously have been only possible with Flash

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...

[kahei]

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.

why do you run gnome?

[HanzoSan]

Gnome is for the desktop, not for your 3d rendering workstation,

Re:why do you run gnome?

[Anonymous Coward]

I don't run GNOME. E is Enlightenment, remember? And right now I'm using Openbox.

My girlfriend uses GNOME, though, while I wean her off the Virtual Teat.

Gah! Nooo!

[thatguywhoiam]

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.

Wait... I'm considering it... considering.... aaaaand... I hate it!

3D interfaces are for 3D displays with 3D pointing devices, dude. Furthermore, I don't want things spinning on my desktop. It already tells me how much/what kind of data it is (in OS X, anyways... its a option to show a label below the filename).

Surprised noone noticed those are KDE icons ;-)

[Roberto]

Yup. The Crystal SVG by Everaldo, and the Sphere by Vadim are KDE icon themes.

Speed vs. Quality

[someguyintoronto]

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.

Re: display postscript not in Mac OS X

[ubiquitin]

Apple is using an optimized PDF rendering engine in OS X, not display PostScript, which had to be licensed from Adobe.

version for Linux?

[GodWasAnAlien]

I hav not seen a linux version of the Adobe plugin. Linux isn't mentioned in that link. Or am I missing something.

Thats a lotta acronyms....

[oh2]

Together with the gdkpixbuf plugin librsvg offer it means GNOME 2.2 will be able to use SVG images

That many acronyms in one sentence is probably bad for you...

Re:sodipodi

[ubiquitin]

Yes, I've tried sodipodi, and it still lacks most of the useful features of Illustrator, including font-file format editing, passably intuitive object handling, drag and drop integration with other GNOME apps, robust gradient support, integration with any animation tool, and cmyk colorspace support. The purpose of indicating these limitations isn't to complain in any way, but hopefully to make clear the kinds of features needed before such a project can be publicly announced as a useful vector graphics tool. Linux has replaced corporate dependence on Windows, and hopefully some day GIMP and killustrator/sodipodi will replace dependence on Adobe's insanely pricey graphics authoring and editing tools.

Re: Stateful Icons?-Think big.

[Anonymous Coward]

Well one a "vector" desktop would be easier to speed up using the native capabilities of most video cards. Two there's also the capability of accurate printing of the desktop when doing snapshots as well.

Umm... hello??

[Anonymous Coward]

It's called Unix? Unix had this like 30 years ago!!

(read: It's called NeWS kiddies. Already there. Use it.)

WTF

[Anonymous Coward]

Monkey boy troll gets informitive, what are there a load of BIG FAT ICON blind fuckes about who wank overthere PC>

Re:the end of diferences?-XUL

[Anonymous Coward]

"XML is a great thing. It could lead to the end of diferences in the look between toolkis and desktops."

This is true. However when Mozilla went for platform independence using XML based technologies. They were vilified. Whaaa! Why don't they just do (my) this, instead of (their) that? Or they're going to be late, were doomed, IE will take over the world. Now look were we are, and what XUL brings to the desktop. It's easy to be a negative, and see the downside in everything (Much like a LOT of the posts I'm presently seeing). It's much harder to have a vision, and see afar.

SVG in KDE

[InodoroPereyra]

So, onto something more positive: what's the state of SVG in KDE?

As far as I know early stages. Check out the KSVG project, they are about to release ksvg 0.1.

Re:SVG in KDE

[Anonymous Coward]

> As far as I know early stages.

Not that early. About 85-90% of the work was done by KDE 3.1. However, more testing is needed before we fully support it in KDE (3.2). Mostly optimizations, bugfixes, and the like.

SVG vs. PNG

[daVinci1980]

I read this claim again and again, and it still doesn't sit well with me. I worked on a vector-based rendering engine for awhile (in fact, the fastest vector-based rendering engine [begins with an f, ends with a lash]), and there are certain limitations that cannot be overcome.

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

[scrytch]

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.

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.

Re:SVG vs. PNG

[t]

Interesting comment. It seems as though you are assuming that an svg image would be composed of multiple objects. Perhaps as things evolve we'll have svg-squishers that optimize an image by removing occluded objects when it is efficient to do so.

The other aspect that needs to be mentioned is that comparing to PNG is rather ambiguous since it has more than one way of performing compression. The catch is that as PNG has tried to squeeze their file sizes further, the complexity of the encoder/decoder has subsequently increased. That all leads to slower performance. In fact, isn't one of the goals of image analysis to break up the scenes into it's base objects, i.e., turn a bitmap image into a vector image?

What I'd really like to know is how fast svg is compared to gif.

Re:SVG vs. PNG

[Minna Kirai]

comparing to PNG is rather ambiguous since it has more than one way of performing compression.

Compression algorithms, or other details related to on-disk representation of a file, don't really matter when evaluating the speed something can be drawn onscreen.

The comparison is between pixelmaps (incidently loaded from PNGs) and vector graphics (loaded from SVG), not between the file formats directly.

A program will read images from disk fairly few times (often just once at startup), but may draw them onscreen 100s of times per second. Loading time doesn't matter in the long run.

Because it's XML, everyone acknowledges that loading and parsing SVG file is not as speedy as possible. It's assumed that SVG-based desktop software will cache the images (either in RAM, or in a non-XML disk file). In the same way, a developer whose program was slowed by PNG decompression times could automatically generate pre-decompressed versions of the image data.

Aside: Although software can handle pixelmap data virtually identically regardless of which file format it came from (jpeg, png, gif, tiff, etc), the more complicated natures of vector graphics means there are many potential differences once the file is loaded. Comparisons between vector formats (Flash, SVG, Postscript, etc) will also need to consider the different capabilities offered by representation. Some may have features which are very slow to implement.

You make a cool icon and save it in PNG, and you're (virtually) assured it'll draw just as quickly as any other pixelmap icon. Labor over an intricately beautiful Postscript file, and you computer may grind to a halt as it refreshes. (Postscript is a Turing-complete language. Therefore rendering a Postscript file can take an arbitrarily long time)

Re:SVG vs. PNG

[t]

Your argument doesn't make sense, if you're talking about loading pixelmaps from PNGs, then you could just as easily load pixelmaps from SVGs, with the benefit that all required resolutions are automatically supported.

Also, the comment about having a postscript file that e.g. is of an infinite resolution fractal is ridiculous. We are comparing two technologies attempting to accomplish similar tasks, not how stupidly one could implement something. If you want to go that route, then how slow would it be if I generated my icons at 1e9 x 1e9 pixels, scaling to the appropriate size on loading? Or is loading time (and resources) really irrelevant?

It also doesn't take into account the task at hand. Suppose you're doing flow charts, then having many images of arrows at various orientations would quickly become obnoxious. Not to mention the task of combining the image of the arrow with the rest of the elements on the screen, you cannot merely blit it to screen.

Re:SVG vs. PNG

[Minna Kirai]

Ignoring most of the response, as it has nothing to do with my argument (or the one put forth in the grandparent post). The main point made by DaVinci1980 is that comparing the rendering speeds of PNGs and SVGs is not a simple exercise. All PNGs of a set resolution will unpack in the same time (+/- 50% for compressability). But for a set of SVGs of the same output resolution, there is no bound on how much longer some of them can take to draw.

It isn't safe to assume that all the SVGs you'll be handed will be optimally built to use exactly as many vectors as they need, and no more.

not how stupidly one could implement something

Many people misquote it, but Murphy's Law is "If there's a wrong way to do something, someone will do it".

Today's developers and artists who create icon sets (or application button-images, or similar) are prevented by the pixelmap technology from creating images so complex that they take too long to display.

A widespread use of SVG in these roles will allow developers to inadvertently produce too-complex artwork for icons. Sure, it looks great on the artist's 22 inch monitor, and he doesn't think it refreshes slowly at all. But after I download the app onto my P133 and run it alonside 7 other programs, I might form a different opinion.
Alternatively, automatically generated SVGs (thumbnails of documents, for instance), can balloon to excessive size if nobody's careful.

Those are just 2 scenarios where the unlimited complexity allowed by vector graphics can lead to unforseen dangers (the UI system getting choked up on an unreasonable SVG). It's easy to imagine more.

Someday software will incorporate smart filters which downsample offensively-large SVGs into their most visually important elements, but this won't be soon.

(My opinion of SVG speed is biased by experience with Sodipodi, which can hardly even display an 800k computer generated SVG on my 1.8ghz P4. Editing it is completely out of the question)

Re:SVG vs. PNG

[entrigant]

So you just used .. 6 semi-paragraphs to explain that vector graphics are a lil' more complicated and can possibly be slower than png rendering? Big deal.

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?

I'm assuming this is a list of things that can impact the speed of rendering. If that is the case, what is your point of making this list ... ? .. I've read and re-read your post and I still can't make out the point you are trying to make. My best guess would be that vector graphics can be faster or slower than rendering a plain bitmap. In that case I don't understand WHY you are making that point.

Yes a bitmap can be tossed onto the screen pretty quickly, but SVG is much more complex and customizable. The implies a speed hit. If we aren't going to try and develop new technologies to do niftier and nicer things with then why are we trying to develop faster computers? To use your video card analogy you could say "why use multipass texturing with customized shaders when single pass generic texturing is faster?" There are some people out there (like me) who think it'd be pretty cool having computers with interfaces like the ones on the Final Fantasy movie. I like KDE's drop shadows and translucent menus. I like anti-aliasing text. I LIKE SVG.

Bring it on.

(Oh and btw... flash the fastest vector based renderer? Make big claims much?)

Opportunity for KDE and Gnome to work together

[Anonymous Coward]

As both of our desktops are getting ready for SVG graphics, and many of the standard graphics elements, which are classically bitmapped, it would be a great opportunity for KDE and Gnome desktop developers to get their heads together, think what they want and need for getting SVG on the desktop, and work together on unifying the look and feel of their desktops, through commonly shared SVG icons, widgets, window styling, backgrounds, themes, ...

Re:Opportunity for KDE and Gnome to work together

[rwlbuis]

Talks have already begun for this. Quite how it will end up we'll have to see. Rob.

Re: Stateful Icons?-Think big.

[ajs]

One little nit (though I agree with you, fundamentally), when you say "accurate" printing, you're making assumptions about what that means. If someone considers accurate to mean exactly what they see on the screen, then you should send that bit-for-bit to the printer with one exception: color correction, which you have to do do account for printer vs. monitor differences in color.

However, if you start re-rendering the screen in the DPI of the printer vs the screen, you will get a DIFFERENT image. That might be ok, or even desirable, but it's not quite "accurate".

These issues are important as we move UNIX-like OSes into the pure desktop arena. We'll have to tackle issues that are purely aesthetic and don't really have a 100% right answer.

Learn more about What SVG is before for you speak

[man_behind_the_time]

Slashdoter,
Here is more infromation about SVG ....to help those that can not...or will not help themselves:

The main community of SVGers lives at:
http://groups.yahoo.com/group/svg-developers/
(have to login...I know it sucks ...but thats what you have to do

There is an SVG Wiki that has a lot of useful links:
http://www.protocol7.com/svg-wiki/default. asp

There is a second ever SVG conference SVG Open 2003:
http://www.svgopen.org/
To read the paper from last years conference SVG Open 2002:
http://www.svgopen.org/index-2002.shtml

Some interesting sites at:
http://www.kevlindev.com/
http://www.mecxper t.de/
http://www.svgnotebook.com
http://pilat.fr ee.fr/english/
http://www.pinkjuice.com/svg/

remember we all learn by sharing what we know
man_behind_the_times

Silicon Graphics IRIX

[almaw]

I can't believe no one's pointed out that IRIX has had scalable vector icons since for ever.

It's one of those things that's quite cool when you first of all play with it, but isn't really a "killer feature".

After all, desktop resolutions aren't going up in terms of dpi that quickly. 48x48 icons on Windows are more than sufficiently large at the moment. 64x64 and 128x128 support is in the wings, too.

I don't think monitor DPI gets larger faster than software is developed, therefore you'll never really need to "stay on top" of monitor resolution developments. It's just a natural progression.

Besides, at anything less than about 50x50, SVG icons aren't a very good idea compared to a hand-optimised bitmap - they're ugly.

Truetype fonts would look *awful* if they weren't full of information about how to grid-fit themselves at low res. That's why tahoma/verdana look so good at 8pt. on screen.

SVG doesn't have anywhere for this information about grid-fitting to go. Plus doing it in colour rather than B&W is a big issue too.

What's new about it?

[Theovon]

There have been countless vector graphics formats since the beginning of computer science, and presumably all of them have been scalable. What's different about this one that makes it better and/or will make it not die like the rest of them?

The concept has been around years....

[Anonymous Coward]

I am sitting in front of a very old SGI and it has scalable vector icons... it even has a roller zoom control at the left edge of the window.

Even the mouse sprits are vector graphics.

I don`t know how old the IRIX box is but its been around at least 4 years.

Its currently running IRIX 6.5...

Improvement for visually impared

[dnoyeb]

This will be a gread improvement for the visually impared as screen magnifiers will look MUCH better.

Re:the end of diferences?-XUL

[protomala]

Yes, you're right (and I admit it even that I don't like XUL because I think it's too bloated, good idea, bad implementation IMHO). XUL is already a wrapper over gtk that works pretty well. Kudos to Mozilla team.

"... not only do it render them ..."

[noshellswill]

' ... but also it be way cool ...' Editor? Gawd sakes, do we be havin' a /. editor or is this another weinerized BASH-shell construct ??

It's time for vector graphics-based GUI.

[master_p]

Bitmaps should be made a thing of the past as soon as possible and GUIs must deal with the screen as an array of virtual points instead of pixels. Microsoft Windows does it, but not completely and certainly not on the icons. The X-Window system does not do it though, and it is really annoying when a good icon layout is destroyed because of resolution change.

When it comes to GUIs, video resolution should be independent of the GUI resolution, allowing for on the fly zoom and video res change.

Not to mention that the GUI looks much greater!

And in the future, each icon can be fully 3d (and rendered by the video card) to give feedback about the status of the file/device: a spinning cd rom, a folder opening, a file being deleted, etc.

svg links

[bolger]

links to interesting various domains using svg; svg examples

Scalable

[riqnevala]

Whoa! I got 2.8Megs of scalable icon for my word-document. If I zoomed it to fullscreen, I can read the document without opening the actual file! No more MS Word crashing, it's all svg now... :)

Well, I like the svg idea, especially the flash_out_the_window_in_a_flash part of it. But even more, there's x3d coming, and hey(!) - have we all forgotten about fractal graphics? Zoom that!

Found the XP screen shot

[oliverthered]

XP Icons
Seems like microsoft only have two Icons.

Recycle Bin sounds like an emerge command on gentoo.

sharing

[bicho]

I have some doubts about the state of the art today.
when an icon is drawed, say, for the gnome menu, it creates a pixmap.
Is that pixmap shared/memcopied for any other app/whatsoever that needs to render the same icon?

when we do it with svg, you could also save time if you only render the icon once.

How does gnome goes about it?

Sorry, but you are wrong

[sorotokin]

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.

Have a little imagination, people.

[keith_veleba]

I see all the chatter about how you tradeoff CPU for RAM savings when using SVG, bitmaps are much better, XML parsing speed, etc.

You guys are missing the point. It gives a jumping off point for many new ideas. Why not a SVG-based window server? Let's get rid of X11 once and for all!! (asbestos underwear deployed) Would gzipped SVG be smaller in size than gzipped X11 when transmitted over the wire? Might make remote desktops as ubiquitous as the web browser is these days.

Also, use your 3D card to offload the process of drawing of a display to where it makes sense.

Isn't that what Quartz Extreme on the Mac is all about? I know only specific configurations are supported, but the idea is sound.

Display PDF and QE seem to be working for them quite nicely.

Just a thought.

Re: Stateful Icons?-Think big.

[Webmonger]

You know, in my experience an "inaccurate" SVG screenshot would would actually be better than the real thing.

Open???

[sorotokin]

It depends on what you call open. It is definitely not open in W3C terms:

• You have to accept license agreement to get it (and you should ask company lawer if you can accept it before you click "Yes" - it has some real implications, it is NOT simply "you should know that we hold copyright" type of things -read section 3 "Restrictions").
• The license effectively says that it is Macromedia implementation that is normative and the "spec" is informative.
• Where is patent policy?
• Can I participate in the future SWF format development?

Otherwise, yes, you can write your SWF player or save to a "Macromedia Flash (SWF)" format.

Why Not...

[somethinghollow]

Why is SVG the future of desktop icons and NOT the future of the DESKTOP. For God's sake, why aren't all window managers/windowing systems vector based? It only seems logical.

Quartz Extreme got potential.

[cryptochrome]

One would hope it would pave the way to a better OS X Aqua environment.

The fact is, OS X is just a short step away from a resolution independent graphics engine. Quartz already renders and scales in a fundamentally resolution independent manner. Quartz Extreme uses the graphics cards to speed much of that - and those graphics cards were really designed for 3D scenes where elements constantly change resolution.

With some work, and some updating of the APIs, we could have a completely resolution independent OS X environment. Instead of selecting lower pseudo-resolutions on your monitor control panel , we could be draging a slider to resize the monitor resolution on the fly to anything smaller than the maximum supported resolution of the card. (Note: yes, even bigger than maximum supported resolution of the monitor). SVG would probably replace tiff for the most part, but scaled, higher resolution tiffs would probably do the job as well.

Frankly the APIs are the main problem - since nobody has ever done something like that before, the Cocoa and Carbon APIs and Interface Builder need to provide for more flexible ways to define positioning information and for rendering bitmapped graphics (allowing programs to choose whether to scale like the rest of the environment or constrain themselves to the native bitmap of the monitor).

Wow

[Anonymous Coward]

that desktop looks exactly like my KDE desktop....

Check out Fresco

[kentyman]

You may want to check out Fresco, which would allow exactly that. In particular, the Fresco vs. X page might be interesting to you.

Cartoons only?

[Eil]

Okay, I know what SVGs are. I know their purpose, their utility, etc. But I haven't actually worked with them and don't currently know anyone who does. My question is this: Are you limited to cartoonish-type images using SVG or are they a great deal more flexible than my little mind can comprehend?

People should stop over-abusing TLAs.....

[Free Bird]

SVG stands for Silicon Valley Group, dammit!

ROFLMAO...

[Anonymous Coward]

Mod this up guys...this fellow is fsck'ing hilarious.

Background?

[SmileeTiger]

Ok I like the nice shiney icons but where can I find that background??

Smilee

Majorstep is Apache's BATIK !

[Anonymous Coward]

This is real opensource, full complient SVG implementation !

The latest is just impressively fast ... compete with adobe without any "adobish limits".

Re:the end of diferences?-XUL

[Nicopa]

XUL a wrapper around GTK?

You know nothing. Please, try to hide your ignorance a little harder. How could XUL be a wrapper around GTK+ and run in Windows, OSX, OS/2 without GTK+?

XUL is a markup language which is just rendered as an HTML variant by the Gecko layout engine.

XUL bloated? XUL works reasonably fast. I don't know where did you take the idea of XUL being bloated.

When people talk about the ignorant crowd at Slashdot they are talking about you.

we arleady have one..

[pastorBernie]

we arleady have a vctor based UI.. its called Fresco

Just remember...

[Cinematique]

640k should be enough for anybody.

Amazing Networking Potential

[Anonymous Coward]

This leaves open an amazing new potential for X networking. Imagine if rather than sending pixels networked X programs actually just sent SVG data to be rendered on the other end. It would cut network traffic immensely :). (I believe HP researched a Postscript X server earlier in this fashion).