Slashdot Mirror
KDE To Adopt SVG: Take A Glance
Karma Sucks writes "According to the KSVG website, KDE 3.2 will be adopting SVG in a very real way. A special preview of KSVG is available, showing everything from font rendering to a snowfall simulation using ECMAScript and DOM. KSVG is fully integrated into the KDE framework and can be used as a KPart -- e.g., by applications such as Atlantik."
The KDE team needs to do more than just adapt SVG as a plugin, they need to render the whole interface via SVG. Maybe cairographics could be used as the backend, and KDE's UI, Icons, Widgets etc could be completely resolution indepedent and rendered via SVG.
People don't exist to serve systems, systems exist to serve people.
I don't understand why they don't just work on cairographics and then port KDE to SVG.
Seems ridiculous to integrate ECMAScript
in there, when we could instead use
python.
Hamsters are at least as feathery as penguins. HamLix
WHY did they make another wheel for their "K"ar. Gnome has had SVG support for ages with librsvg! Heck I can even have SVG wallpapers on gnome! I often draw SVG diagrams with SODIPODI and libsrvg renders them fine, while KSVG makes them look like whats in the toilet.
Once again, reinventing wheels is whats killing opensource on the desktop!
If we can all see this why cant they? I dont know what their goal is with SVG, but do I really care if SVG is a Kpart if its not truely a part of KDE or X? Everyone here please check out http://cairographics.org/ CairoGraphics is a project working on making the entire interface SVG, and allowing my state of the art graphics card to render that interface, this means speed. I don't want a cheap software rendered SVG hack which wastes CPU resources, I want it to be done right, why do we have all these SVG projects when they could just merge into one project?
People don't exist to serve systems, systems exist to serve people.
Now we can finally play Asteroids in all its full glory ;)
Banaaaana!
When are they going to fix the ****ing file dialog? Oh wait, thats that *other* desktop.
does it have to do with grafics performance?
I am the Alpha and the Omega-3
So Konqueror will have decent SVG support now.
When are we going to get decent working SVG support for Mozilla (and Phoenix) in X then? Last I checked, we're still stuck with libart (which can't be officially included in Mozilla thanks to the lack of a tri-license) and the infamous Bug 111152 was still open...
Wow, that's really awesome. I can't wait for Safari to have those features.
As a KDE fan I'm pleased to see this. SVG is an important standard. It's too bad that Microsoft has not embraced it it IE (nor will it ever). Flash is still a great medium for vector animation and now it can even be used for real applications using Laszlo's LPS and their new LZX language.
As seen on Wired: Get a free desktop PC
You should be modded up because you actually have a point, the Gnome developers are the ones doing all the cutting edge stuff. Like storage http://www.gnome.org/~seth/storage/ And also they are actually attempting to use SVG to render the entire interface including widgets, not just icons. http://developers.slashdot.org/article.pl?sid=03/0 2/03/129215&mode=thread&tid=152&tid=106&tid=13 1
http://librsvg.sourceforge.net/
What I dont understand is why we need 100 different SVG projects when we could get more accomplished if we all worked on cairographics.
People don't exist to serve systems, systems exist to serve people.
SVG is a new way to render without pixels, it requires less ram but more of a CPU hit, since our CPUs arent actually being used its a fair trade off for resolution indepedance, speed, and special effects. It could allow Linux to compete with or even surpass OSX and Longhorn.
People don't exist to serve systems, systems exist to serve people.
Seeing as how the VP is such a VIP, shouldn't we keep the PC on the QT? 'Cause if
it leaks to the VC, he could end up an MIA, and then we'd all be put on KP.
Well, this could bring some great new (usable) flexibilites to the KDE - completely scalabe icons sound way better than that mess of 6 different resolutions of png files. Let's hope it also scales, resource wise...
This is extremely cool for many reasons.
:-) It's also quite likely that once the KHTML integration is complete, it will end up in Safari as well, which is good for everyone.
:-)
1) It means that KSVG, which was stalled for a long time, is now stable enough to be considered part of the base system. That is good news for SVG adoption in general, as it means that Konqueror 3.2 will likely have native SVG-with-animation support. Finally, an out-of-the-box fully-SVG-enabled browser other than IE-with-Adobe.
2) SVG should not be used for the entire UI, that's overkill, but for many areas it makes life a lot easier. For instance, icons in SVG make them infinitely scalable, so that people can resize their screens or their icons to whatever they find comfortable with no loss of quality. (Think handicapped.) Also, no more need for Small and Large versions of icons. Just have one icon, and the system scales it to whatever size is needed.
3) Hopefully, this will mean better support for SVG creation. KDE's SVG editing tools are still not the best. What I really want is to be able to use SVG as an editing format natively, not have to use a program-specific format (Illustrator, Kontour, Karbon14, anything) and then export to SVG. I want to work natively in SVG. With luck, this will let us do that.
There are some potential downsides, of course. Most notably, the risk that KDE will become like Mozilla. An all-XML UI, which while flexible also makes it considerably slower than just using compiled widgets. KSVG will have to be very very fast to avoid that problem, unless things are precompiled in memory cleanly.
Still, I can't wait.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Objects can be clearly rendered in SVG regardless of the output device resolution.
We are seeing small 15" laptop screens with resolutions of 1920x1200. Soon we will have desktop monitors with higher and higher resolutions. This is because the profit margin in low resolution LCD monitors is quickly becoming very thin. Manufacturers are going to try and differentiate their products by touting the clarity and color rendition of better, higher resolution screens.
So the operating system designer doesn't have to
- Create an icon for each resolution
- Use icon scaling
- And make many sections of code that will make sure the important things are on screen and usable.
Many applications could and should run well on a PDA (4", 200x320) a cell phone(1.2" 90x90) and a scientific visualization workstation (120", 6400x4000) without device specific code or modes.The smaller reasons include much less data - if a graphics card rendered SVG, then the connection between the computer and the card could be slow and very long distance. Hard drives space isn't an issue, except in power-conscious embedded areas where smaller graphics files could make a difference.
Lastly, rendering speed improvements could be realized. Aside from dedicated HW doing the rendering, if the OS did it in a trusted manner then it could be faster than many libraries and/or programmer hacks. Programs could as a result be smaller, since they don't have to maintain as much graphics, layout, and UI information.
In short, there are many good reasons to include SVG in the lower system level - mostly looking toward the future of hardware, but when it's here, won't it be nice to be ready?
-Adam
"The original title of this book was 'Jimmy James, Capitalist Lion Tamer' but I see now that it's... 'Jimmy James, Macho Business Donkey Wrestler'... you know what it is... I had the book translated in to Japanese then back in again into English. Macho Business Donkey Wrestler... well there you go... it's got kind of a ring to it don't it? Anyway, I wanted to read from chapter three... which is the story of my first rise to financial prominence... I had a small house of brokerage on Wall Street... many days no business come to my hut... my hut... but Jimmy has fear? A thousand times no. I never doubted myself for a minute for I knew that my monkey strong bowels were girded with strength like the loins of a dragon ribboned with fat and the opulence of buffalo... dung. ...Glorious sunset of my heart was fading. Soon the super karate monkey death car would park in my space. But Jimmy has fancy plans... and pants to match. The monkey clown horrible karate round and yummy like cute small baby chick would beat the donkey."
-- Jimmy James
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
kde kan konker kountless desktops with fantastik new applikations like ksvg and kpart, but I really krave for a less krappy naming skeme that kould help even out the wear on my keyboard ...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Look at the Fresco project. They are making resolution independent display system whose widgets are all SVG.
I'm surprised he hasn't posted the google cache in this thread.
Is it just me but the interface looks very polished? Maybe using SGV for rendering is an answer to Apple's Quartz engine. I think it's time to put bitmap graphics system behind...
"Well, work is ongoing which would make the backend pluggable. This has resulted in a GDI+ version for windows, with fewer bugs."
Plugin vs embedded.
Now how easily accessable is the DOM?
What will that mean for things like SMIL?
--Dateline, October 14th-- GNOME project team announces they will be adopting SVG in a very, VERY real way.
Seriously, people. Thesauruses are your friend, ok? :-)
Please help metamoderate.
"There are some potential downsides, of course. Most notably, the risk that KDE will become like Mozilla. An all-XML UI, which while flexible also makes it considerably slower than just using compiled widgets. KSVG will have to be very very fast to avoid that problem, unless things are precompiled in memory cleanly."
Or your using that $300 GPU you spent all that money on to do the job.
Now wasn't there a reason you bought it?
SVG, whether you like it or not, may very well be the future as far as graphics...at least as far as GUIs are concerned.
Scalability has become increasingly more and more important on the desktop in recent years, and it's nice to see KDE recognize that.. Beyond the savings associated with going vector over raster, it's just a better idea. A better tool for the job. Sure, it's not going to replace traditional rasterized images (i'd imagine it's pretty hard to distill a rasterized image into a decent vector) but it's a step in the right direction. The right tool for the right job.
Cheers,
Bowie J. Poag
Here's a torrent of the page and screenshots...
KSVG Torrent
Lets be realistic.
People don't exist to serve systems, systems exist to serve people.
I always get turned around when viewing screenshots which use the same theme as I do - I always end up trying to click on the widgets on the screenshot instead of my own =]
Pretty neat stuff, nonetheless.
political_news.c: warning: comparison is always true due to limited range of data type
Theres a world map on the page, with some nice text, shading, etc. It says it took 6 seconds to render.
My computer (and anyone else's with a modern 3d card) can trivially render a scene consisting of multiple animated 3d models with 10s of thousands of polygons each, with lighting, anti-aliasing, real time dynamic shadows, reflections, etc, in a miniscule fraction of a second.
I'm sure parsing this format adds considerable overhead, but you can parse a large amount of pretty much anything in a fraction of a second on todays multi-ghz processors.
So why does it suck so much?
And when is someone, anyone, going to use the BIPs
of processing power available on graphics cards today to make our desktop experience as snappy and attractive as our game experience has become?
begin my_ph4t_backgrd.sVg
hey computar plz draw a box enuf to fit 3 peoples heads
then on top of dat google for "sum41 group photo" an
put tat on top. oh yah and center it please.
engage!!1
EOF
I don't really see the problem. SVG is probably the easiest way to describe a picture structurally behind, I don't know, AppleScript or forth.
Fuck Beta. Fuck Dice
what is the app that looks like the mac os x dock in those screenshots?
For those of you who don't know, SVG = Scalable Vector Graphics
go for it, boy! cut it off!
Wow! That's kind of new worth to be published on the frontpage of /. ! Where did you get that fact? Any link to share with us?
Last time I've checked XML had nothing in common with HTML aside of the braket shape.
For object-oriented nature of XML with strong namespacing I would definitely prefer to use a real language with strong typing rather than that mockup, which was Javascript.
Less is more !
In longhorn the entire UI will be vectorized and scalable via hotkeys. Icons, buttons, fonts, whatever. So that if you have that 200dpi IBM monitor you'll be able to just set up the scaling and move on.
Scaling will be even supported in old non-vectorized "compatibility mode", but of course you'll see pixelation in this case.
To all the people who have been saying that SVG would make it unnecessary to have different icons for different resolutions, I must say that icons are not thumbprints. You would still have a need for different icons, depending on the amount of detail the interface is capable of rendering. A single SVG icon would be either too plain for a 1600x1200 screen or too complex for a 90x90 cellphone display.
NO ONE is going to make MY backend pluggable! Go away, fags!
Nice to see kde still trying to KATCH UP!
A troll, still desperately waiting to get a FOLLOW UP! *giggle*
Just talked to Capzilla over from Unixcode.org - he's getting flooded with requests right now so be patient with his server. Sometimes /. readers are like a pack of wolves to descending on a poor defenseless webserver.
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
This is just about where we were with NeXT and Display Postscript. :)
"Draco dormiens nunquam titillandus."
Adopting SVG for icons,etc for a Linux window manager to me is a bit trivial.
Having worked with the spec, it hasn't seemed to take over the web, probably due to the lack of editors for it that let you take full advantage.
Flash killer it is not. We need Windows apps that aren't half-assed that do NATIVE SVG support. Exporting and importing just won't cut it.
I won't be impressed until Adobe soups up the plug in and we can play a port of Half-Life with it.
Yup, he karma whores so that he can post his Amazon referral posts with a positive score and make money from unsuspecting slashdot readers. He is a spamming piece of shit. One way he karma whores is by ripping off other people's reviews and passing them off as his own.
...at least as I recall, and support for this probably even sooner.
Of course not all themes are completely SVG, but the functionality is there, and excellent complete SVG themes do already exist for GNOME.
We've been expecting this to pop up in KDE for a while now.
Can somebody tell me why SVG would be implemented using XML? I mean .png, .gif, and .jpg don't use verbose ascii storage formats do they?
What ever happened to compact binary image formats?
I would say "Yay! Interoperability! Gnome and KDE going the same way on something". Except I can't see how SVG is any faster, unless the X protocol makes vector operations much more efficient than just slapping bitmaps about. *sigh* Well, at least there are more than just 2 linux window manager / desktop environments. /me goes back to icewm. Makes my P233 linux box look like a DX4 ...
Then we can run in 1600x1280 on a 15" monitor with SUPERSMOOTH everything! That would be so awsome. Just scale up on the graphics for the high-res small screen! Woot!
Ezri (the server) is doing fine and somehow my ISP is decent enough that my downstream barely seems affected. But true enough, outgoing bandwidth (200kbit/s, pretty much dedicated at this hour of the European day) is fully used at the moment, so loading might take a while. Of course this only applies to the Atlantik URL, KSVG is hosted on one of those neat KDE servers.
Will adjust the stylesheet not to load the marble background images, that should help a bit.
Of course not all themes are completely SVG, but the functionality is there, and excellent complete SVG themes do already exist for GNOME.
We've been expecting this to pop up in KDE for a while now.
that should help
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
One step at a time please. There is already some talk on the mailinglists about this. Probably something for KDE 4.
Gee, I read on the KDE page that they currently have 3 developers and would welcome help. I say "thank you" and lending a hand, if possible, is more appropriate than criticizing their efforts as "not good enough" and demanding more.
It's open source. Be glad for what you get -- or go ahead and ask for your money back!
quiquid id est, timeo puellas et oscula dantes.
I'll believe it when I see it.
#!/
Thats what CairoGraphics is for, its supposed to fix that problem.
People don't exist to serve systems, systems exist to serve people.
It is not bad to have someone point out what is needed with a project, in fact it is a good thing.
You don't have to do anything about it, bu if enough people say the same thaing, the people that are developing it can see whether ot not there efforts will be wasted because no one will use what they are developing.
I wonder if you complain about politics?
The Kruger Dunning explains most post on
God no! It's slow enough as it is. I'm not trolling. I find it virtually unusable due to it's lackluster speed. Wouldn't rendering everything by SVG just make it worse?
History has shown folks are loathe to download plugins to view content, and without a market for content there's little for content creation tools, leading to little content etc. Thus SVG may suffer the same fate as PNG & VRML: Better formats ignored by an indifferent market, relegated to a niche arena of hard-core standards & web technology geeks.
Using SVG, or indeed any vector-based GUI, is indeed a probable long-term win and "the right thing" to do. However there's also the strong possibility that SVG may remain stillborn and this could all be a dead end. Time will tell but right now SVG isn't the obvious next big thing it was a year or two, is following a trajectory disturbingly similar to, again, PNG, VRML, and many other also-rans.
ps. Yes there amy be folks out there using PNG & VMRL but let's be honest they're not exactly common formats, and they don't seem to be becoming any more so in proportion to everything else.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
hey asshole, its still legible
don't be a twat over semantics
Ah, ok. I'll only click reload twice then, instead of four or five times like I usually do.
> The KDE team needs to do more than just adapt SVG as a plugin, they need to render the whole interface via SVG. Maybe cairographics could be used as the backend, and KDE's UI, Icons, Widgets
Who said that they aren't doing this? The story links to Atlantik, which is being rewritten to use SVG for it's UI. The preview shows icons being rendered with SVG. KSVG also makes making Qt widget styles using SVG possible.
Please read the article before commenting. =)
TrueType fonts are scalable, but they render very quickly. That's because they are actually cached as bitmaps. The KDE team will likely do the same thing with icons, and if they extend SVG to the inteface, they could do the same thing there.
Ok, I've been following SVG for a little while and I'm excited about its prospects.
Most of you have probably seen the SVG demos at Croczilla.
I once had a Mozilla 1.3 Alpha with SVG build, and it rendered these files perfectly. I was using Red Hat at the time.
Now I'm using Gentoo, and I emerge Mozilla with mozsvg in my USE flags, which of course builds an SVG enabled Mozilla. Cool.
Except that the croczilla files look like crap. They are rendered B&W, all color is gone. AND the image gets corrupted every time 1) you open a menu over it, or 2) part of it is manipulated with DOM. None of this was a problem with that old build I had.
I also just downloaded the latest SVG build from Mozilla's site, in case there was something wrong with the ebuild process. It had the same problems.
My questions:
1. Is everyone else getting the same screwed up results when viewing SVG in Mozilla? If not, I'm wondering if there's a problem with a library I have installed.
2. Has anyone tried the Croczilla files with a recent Konqueror CVS? Do they work? Including the DOM transformations?
Thanks!
I remember that RIP was the first vector graphics interpreter for dial-up BBS' in the late 80s/early 90s. It required a special client but it made the BBS experience that much nicer.
It makes me wonder: why it took so long for it to be incorporated in some fashion as a web standard?
The core KDE libraries are LGPL'd while most KDE applications are GPL'd.
But Mozilla is licenced under GPL, LGPL, *and* the Mozilla Public License, which is not GPL/LGPL compatible. (Correct me if I'm wrong; that's a possibility.)
The Mozilla Project only accepts code if the author distributes it under all three licenses. I believe someone could make a branch of Mozilla and only license it under the GPL or LGPL, thus eliminating the licensing issue.
Too bad nobody gave a shit about svg until recently (unlike antialiased text, which kde had for more than a year and a half before gnome did)
Of course, svg will never take off until IE gains support for it (png took off when IE 6 added that)
Too bad IE doesn't have any competition left, I doubt MS will release a new major version of IE before longhorn.
Currently on their examples page, they have a pretty complex map generated in SVG:
Our speed testcase. 1.8 MB. The fastest rendering time was around 6 seconds on a 1,4 GHz Athlon. WITH progressive rendering. (At the bottom of the page)
Rendering so much XML data that quickly is commendable, but to push the envelope it really needs to go into hardware - maybe this would make a nice addition to the Graphics cards of the future?
Also the other anonymous poster who replied to you is correct - they WILL find ways to optimise the rendering, and then we will all benefit.
liqbase
Nice to know it's Something Very Good.
...they're slow. Postscript gets around the speed issue by caching a glyph once it's rendered at a specific resolution and then using the rendered bitmap instead of re-rendering the vectors. It's kind of pointless to re-render every icon on a desktop every time it's exposed.
So, you cock-smokers have a web browser the rest of the free world had in fuckin' 1993, yeah, I'm all out of gold stars and parades. what's next, the fuckin' thing sends mail, too? there are Turkistani mud ovens with better browser functionality than this. go run 'uptime' and 'sasteroids' and fprot your tarballs.
ugh, KDE
Before talking about this as the "future" of linux desktops, you may want to take a look at the license restrictions on SVG itself.
You'd better be glad I don't know your home address! Your mom's hot, too.
Really? What kind of machine are you on? On my 2GHz P4, its right up there with XP (like that's saying much :), but then again, this is 3.2 CVS on a 2.6-test kernel...
A deep unwavering belief is a sure sign you're missing something...
Please use SVG to describe the field and location of the players.
First, everything is named with a letter K, then, what's with that juvenile aquafied icons look! This is almost 2004 now, we're well over the late-1990s OS X cheap clones.
What theme did they have in those screenshots, or is that how the new KDE is gonna look? I think it was awesome and I want to have mine look like that, I just need to know whether or not I have to upgrade or just go to themes.kde.org. Cheers, Steve
Lastly, rendering speed improvements could be realized. Aside from dedicated HW doing the rendering, if the OS did it in a trusted manner then it could be faster than many libraries and/or programmer hacks.
Yeah, right, let's put everything into the kernel. You can see how well that worked for Windows.
Both Linux and Macintosh have client/server GUI systems that do rendering not in the OS but in user mode processes. That's the right way to do it. Something as complex as a GUI does not belong into the kernel (the "OS"). However, display-side SVG rendering in X11 would be a welcome addition, and that is being planned. That will give people the same kind of features that Apple gets with DisplayPDF, but with a somewhat cleaner and far more standards-compliant graphics language (SVG vs. PDF).
The smaller reasons include much less data - if a graphics card rendered SVG, then the connection between the computer and the card could be slow and very long distance. Hard drives space isn't an issue, except in power-conscious embedded areas where smaller graphics files could make a difference.
Pretty much all graphics cards these days have 2D acceleration. Therefore, computers already communicate them using vector graphics operations.
Objects can be clearly rendered in SVG regardless of the output device resolution.
You're confusing representation with graphics model. SVG gives you a text-based representation of an object-based graphics model. You don't need that for geometric scaling. Postscript, DisplayPostscript, OpenGL, GDI+, and XRENDER all give you geometric scalability without anything like SVG.
Furthermore, rescaling GUI objects is not simply scaling them geometrically. Support for scaling graphics in the the window system will help somewhat with scaling over a limited range, but it won't magically make a UI or even an icon scale from PDA to huge screen sizes.
SVG is useful and it will come. But it isn't the panacea that you seem to think it is, and it isn't all that new either.
SVG is already widely used and supported in Gnome.
That would be a major change for KDE, given that Qt is such an integral part. However, it might actually be a good way for KDE to eliminate their dependency on TrollTech and replace Qt with something LGPL'ed--the Qt license has been a major obstacle to KDE's acceptance I believe.
Right, so...
What the hell happened to the guy's taskbar?
Syntax dicksnap. Semantics is the meaning which as you say is ascertainable.
It seems that there is some duplication of work. One group of people is working (with some success) to replace the older X11 bitmap fonts with outline fonts drawn at the right resolution, anti-aliased, and (modulo legal obstacles) hinted. Another group is replacing pixmap icons with SVG files rendered at the right resolution and again probably anti-aliased. Couldn't there be a single piece of code to do both? Why not use SVG to describe glyphs?
-- Ed Avis ed@membled.com
I hear a lot of people complain about KDE because it's "too slow." As I recently left Gnome in favor of KDE 3.1.x (since its file manager isn't a component of the goatse dude like nautilus) and I've found that on my Athlon XP 1600+ and my Duron 650 that it runs just fine. It runs as well as Windows as far as speed goes.
I mean, KDE isn't going to run well on an old Pentium (my assumption anyway) but OS X and new versions of Windows aren't going to run on yesterday's hardware either.
Generally if you use yesterday's hardware, you better get used to yesterday's software. The nice thing about Linux is that I have a choice. Fluxbox, Xfce, Gnome, KDE, Rat Poison, etc.
I believe you've Missed The Point Entirely. SVG is a graphics file format, so generally end-users won't have to write SVG, in the same way that you don't need to know the format of a BMP file to get a wallpaper on your Windows desktop.
BFG, TLA, ETLA and WTF.
As in: WTF is SVG?
If you were blocking sigs, you wouldn't have to read this.
I mean really, you all can doodads galore but if the stupid thing crashes, what's the point?
Which is why TrueType has (proprietary) font hinting: fonts are just scalable vector graphics and they don't scale small and stay readable.
Don't put away your bitmap icon editor just yet...
I am hoping that SVG will do to kde/linux what wmf, pict and displayPS do in other platforms.
Although copy/paste/edit of text in X is very good, the same cannot e said for graphic data, where one has sometimes to resort to a plethora of conversion tools to put the odd graphic on a document.
"I can eat glass, that does not hurt me."
WTF?
<^>_<(ô ô)>_<^>
But there is a compact binary image format for SVG. It's called SVGZ.
Seriously; have you ever seen XML compress? It's a thing of beauty, man.