Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
KDE GUI Graphics Software

KDE To Adopt SVG: Take A Glance 286

Posted by timothy from the lines-and-arcs dept.
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."
This discussion has been archived. No new comments can be posted.

KDE To Adopt SVG: Take A Glance More

KDE To Adopt SVG: Take A Glance

Comments Filter:

  • Thats not good enough! We need an SVG interface! (Score:4, Interesting)

    by Adolph_Hitler ( 713286 ) on Saturday October 11, 2003 @04:35PM (#7191466)
    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.
    • > 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. =)

  • Whoohoo! (Score:4, Funny)

    by Exiler ( 589908 ) on Saturday October 11, 2003 @04:39PM (#7191482)
    Now we can finally play Asteroids in all its full glory ;)
    • Now we can finally play Asteroids in all its full glory ;)

      Everything beside the Atari 2600 version is pathetic and simply untolerable!

      I learned everything I know about flying a spaceship from this game.

      So don't make fun of it, only because the pixels were kind of extensive.

  • And Mozilla? (Score:3, Interesting)

    by PipianJ ( 574459 ) on Saturday October 11, 2003 @04:41PM (#7191490)

    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 [mozilla.org] was still open...

    • how big is libart? In other words, how long will it take to re-write it under a different license?

      Another question: if Mozilla faces such a license problem, why KDE won't? And if KSVG will be based on another SVG library, why cannot Mozilla use that alternative SVG library?

      P.S. At some point GNOME/GTK has been burn just beacuse license issues of KDE/QT. I guess not it may (and actually should!) happen with libart/SVG.

      • I'm not sure if KDE uses libart or not. Probably not; I think KSVG is an independent implementation.

        But, KDE *could* use libart because libart is LGPL. KDE is GPL, and GPL'd code can import LGPL libraries, no problem. 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.)

        If KDE uses its own, it would probably also be either GPL or LGPL, so it wouldn't have any advantages over libart.

        Really it's not th
      • how big is libart?
        >>>>>>>
        About 10,000 lines last time I checked (a few years ago). But its some rather excellent and sharply written code. Rewriting it to its current level of quality would be non-trivial.
    • When are we going to get decent working SVG support for Mozilla (and Phoenix) in X then?

      Adobe has a new SVG viewer plugin in beta. [adobe.com] Currently, only Win32 versions are available, but the lead developer said on the SVG-dev list that they build and test for OSX and Linux. Unlike ASV3, this works fine with current Mozilla/Firebird, but its scripting can't talk to the browser or to the other documents the browser displays.

      For my work with SVG, this doesn't matter, but if you want, e.g. your javascripted html

  • Wow, that's really awesome. I can't wait for Safari to have those features.

  • Somehow, this came to mind ... (Score:3, Funny)

    by John Jorsett ( 171560 ) on Saturday October 11, 2003 @04:48PM (#7191516)
    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.

  • Wicked cool! (Score:4, Insightful)

    by GrouchoMarx ( 153170 ) on Saturday October 11, 2003 @04:51PM (#7191524) Homepage
    This is extremely cool for many reasons.

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

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

    • Re:Wicked cool! (Score:2, Interesting)

      by Adolph_Hitler ( 713286 )
      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. Yeah just like having more than 64 megs of ram is overkill, I mean who could e

      • Re:Wicked cool! (Score:3, Informative)

        by be-fan ( 61476 )
        Too bad you have no idea what you're talking about. OS X is hardly competiton for KDE.

        a) SVG has nothing to do with text quality --- current fonts are scalable, but they are rendered by highly optimzed renderers like Freetype to apply font-specific hinting.

        b) OS X doesn't use vectors. Most things (widgets, etc) are still bitmaps. The graphics system supports vector graphics (and some apps like Quicktime use them) but most of the eye-candy in OS X is just the result of good UI designers. Hell, it doesn't e
        • Wouldn't it be possible to store fonts in an SVG format, then render each character to a buffer for a given point size? In that sense, wouldn't SVG be capable of replacing TTF (TrueType Font) file format? I wouldnt' think it would take much logic to render the longest straight vertical edge to align exactly to a hard pixel break, then anti-alias all edges that don't align to a pixel boundary. I haven't ever seen a TTF renderer, but my guess is that is all that happens--TTF is a vector format, and when a
          • In that sense, wouldn't SVG be capable of replacing TTF (TrueType Font) file format?
            >>>>>>>>>
            No. Fonts are very complex beasts. You can't get good on-screen output by just rendering the font outline. You just don't have enough pixels for that. The TTF and Postscript formats have hinting systems that are used by the renderer to optimize output for on-screen display. TTF's hinting format is actually a complete bytecode interpreter for a specialized language that subtly manipulates
    • I'm sure I'm missing something. But this stuff looks like crappy graphic from a 1989 version of Corel Draw. Perhaps the technology is really cool but those screenshots are VERY unimpressive.
    • Sodipodi is pretty good at SVG creation/editing. It's a Gnome/GTK app though.

      I wonder how long it will be before we have KSodipodi...
      • There was once killustrator.. it was pretty good app before there was ever sodipodi, but for technical reasons (oh yeah, adobe threatening the author didn't help either), it died in favor of karbon14, which while much better technically than killustrator, is worse than actually creating things than killustrator or sodipodi. There was a point where I could do very complex path manipulation in karbon, but it lacked a usable center-oriented rect tool.

        So sodipodi is probably the best vector drawing app right n

    • 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.
      Ummmm, yeah, if we're gonna go for infinitely resizable screens, let's go all
    • 2) SVG should not be used for the entire UI, that's overkill,

      I disagree emphatically. Having the UI stored as vectors means that I can scale up everything - buttons, icons, widgets, everything - if I want, but Mr Only-has-640x480 doesn't have to suffer the obscenity of 40% of screen space going to widgets.

      I recall some testing going on with the GNOME crew a while back where it showed that SVG rendering was actually faster than PNG rendering for some obscene reason (I'm too lazy to care, search back if yo
      • You can be scalable without using SVG. Most theme engines aren't pixmaps, but C/C++ programs. Its easy to make those programs change the size of their rendered widgets. The real problem is that none of them bother trying to autodetect the user's resolution to scale its size.

  • Why is SVG important to the desktop? (Score:5, Interesting)

    by stienman ( 51024 ) <adavis&ubasics,com> on Saturday October 11, 2003 @04:56PM (#7191545) Homepage Journal
    I suspect a number of people are wondering why SVG is important to the desktop. There is one major reason to have SVG as part of the normal program rendering. Several smaller reasons, too.

    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
    1. Create an icon for each resolution
    2. Use icon scaling
    3. 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
    • 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.

      • Re:SVG != resolution-independent icons (Score:4, Insightful)

        by stienman ( 51024 ) <adavis&ubasics,com> on Saturday October 11, 2003 @05:55PM (#7191779) Homepage Journal
        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.

        Oh, come on. It's a simple matter to create a icon that is as complex as it needs to be (ie, you don't need a super complex icon for Staroffice) regardless of the output device.

        It's then a simple matter of 'culling' the detail. on a 90x90 cellphone display, you simply don't render objects that are smaller than a pixel or two. In that case you end up with only the larger aspects of the icon. Furthermore, the device may avoid rendering gradients, going for a solid color, etc.

        The designers ought to be aware of this, however, and make sure there are some larger as well as detailed aspects to every icon.

        But the real idea behind an icon is that it is the same angular size relative to the distance to the human eye, regardless of the resolution of the display device. This means that the icon on a monitor 24" from the eye would be about 1" by 1" regardles of the resolution. Since the human eye has an inherent resolution limitation then certian details are not practical in the icon since they would not be resolved by the eye, even though the display may be capable of rendering them.

        Similarily, a stadium size display need not render a lot of small details since the eye is more than 10 or 50 feet away, and, again, the eye's resolution wouldn't be able to resolve a detail that is only an inch large on the display.

        -Adam
        • From my own experience with raster and vector GUIs I'd estimate the cutoff point is quite high; about 1280x1024. That is, below 1280x1024 you really need to carefully line things up pixel-by-pixel for maximum clarity (I'm talking about typical GUI interface graphics). Only at higher resolutions can you take a hands-off approach and just let the OS rasterize an abstract vector description.

          This means that for really small displays like cell phones, a lot of manual tweaking will still be required for vector-b
          • Your first two paragraphs remind me of why font hinting is required. Fonts are resolution independant graphics, yet they require help with rendering at low resolutions to maintain readability.

            Does SVG have any simple means to create a 'hinting' system?

    • If you want to take a look at what the parent is talking about, just find a Mac running OS X; icons are done via scalable vectors so that the dock can be manipulated without compromising icon quality(size changes, magnification, etc). It's another one of those little things that sounds pointless, but's worth big points with users.

  • I'm ekstatik (Score:5, Funny)

    by Rosco P. Coltrane ( 209368 ) on Saturday October 11, 2003 @05:01PM (#7191561)
    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 ...

  • very real way (Score:4, Funny)

    by SuperBanana ( 662181 ) on Saturday October 11, 2003 @05:08PM (#7191584)
    KDE 3.2 will be adopting SVG in a very real way

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

  • A (tm) Damn Good Thing. (Score:4, Informative)

    by Bowie J. Poag ( 16898 ) on Saturday October 11, 2003 @05:10PM (#7191598) Homepage
    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,
  • 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.
  • For those of you who don't know, SVG = Scalable Vector Graphics [w3.org]
  • 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.
    • 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.
  • This is just about where we were with NeXT and Display Postscript. :)
  • 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.

  • Why XML?? Just why? (Score:3, Interesting)

    by ebyrob ( 165903 ) on Saturday October 11, 2003 @05:55PM (#7191780)
    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 don't know all the reasons why, but one is that it makes handling SVGs and writing applications that handle SVGs a lot easier. The SVG XML DTD really makes a lot of sense when you think how best to codify an image's structure.

      And it's really not a space problem, since you can gzip an SVG (and svgz is becoming a fairly standard format) and make it just as compact as a binary image format.

      So you get a nice, open format that makes a lot of sense, and that can be compacted where necessary. Magic.
      • I'm not sure I buy the "parsing ease" hard-line.

        Now I've got to use a rather complex decompression library and a rather complex XML parsing library just to get back to where I could have started?

        All I see is overhead.
        • I don't see why you see gzipping as a complex barrier; it's rather trivial to add support for it in terms of code.

          And I would have thought that most developers would rather learn a new XML DTD than have to learn an entirely new way of encoding data. If you don't, and you don't like XML, then there's no point in trying to convince you :)
          • XML is good for some things, its just "highly hyped" at the moment, so it also gets used in places it probably shouldn't. (Like everywhere its been used at the company I work... XML would certainly be useful in my industry, but only on an industry-wide basis not within a single small company.)

            gzip is trivial? How many lines of code are in a typical gzip implementation? What is the memory profile during execution and typical speed of operation based on file size? Have you written gzip compressors and d
        • ...because it is an eXtensible markup langauge. The obvious benefit of this is that extensive modifications can be made to the data persistance format without breaking existing implmentations or resorting to the hacky/tacked-on features that so many graphics formats suffer from. Most data formats start off simple, and in comparison having to use an xml parser or compressor seems like unnecessary complexity. But five or ten years from now, after the unavoidable feature creep turns the format into an overly c
          • I tend to be more lazy than anything else, so I try not to put the complexity there in the first place.

            The important thing to remember here is that both XML and gzip are complex to some degree, so they should only be added if they provide some important benefit.

            Also, proper requirements analysis and design, performed seperate from any coding, cannot be obsoleted by a "silver bullet" like XML. If you don't take pains to create useful, flexible, modularized software, at all stages, then the pains will fin
    • It makes it very easy to parse SVG. It also them easier to transmit to different computers with varying byteorders and whatnot. In practice, SVGs are compressed (gzip compression) so there is very little practical overhead for using an *unicode* format.
      • varying byteorders? I thought that had been resolved years ago when "network byte order" was established...
        • Filthy big-endian... I thought we'd wiped out your kind years ago...
        • Network byteorder has nothing to do with this. When yous end binary info over the net, it gets sent as-is. You can convert it if you want, but the network link doesn't just go and change the byteorder of anything going in or out. And it wouldn't work anyway if you got some images on a CD. The byteorder problem is usually just resolved by saying "the data is in little-endian byteorder, deal with it." Putting things in XML gets rid of that problem.
          • Actually it all depends, MIME formats all have a network defined byte order of some sort, and I can send certain "binary" files from MACS to PC's and back and they work on both. All of this was true long before XML came on the scene.

            In fact, JPEG, GIF and all the other image formats are "binary" and don't seem to suffer any bad side effects from being so. Ergo byte-order and machine compatability don't seem like good reasons.

    • The main reason it is XML is so it integrates well with other W3C standards: SMIL, XHTML, XSLT, XSL:FO and CSS. Actually SVG itself relies a lot on these formats. For instance, styling is done with CSS, SVG can easily be generated with XSLT, a lot of SVG text layout attributes came from FO and SVG animation is basically an integration with the SMIL animation module. SVG is not supposed to do everything by itself, and, for instance in Adobe SVG Viewer v6 preview you can embed a pieces of XHTML in SVG and SVG

      • Hmm... that begins to make a bit of sense. Very combinable with other W3C standards. I suppose it works pretty well that way if most images are meant to be created by humans and easily readible by humans. Truly a "markup format" for images.

        As to verbose... Well, gzip certainly helps, but I keep hoping for a compression format tailored to handle XML, or a translated XML format designed for compactness and easy machine manipulation. (Hadn't there been some effort on this in the embedded space?)
  • Sadly Adobe has quietly stopped much of it's SVG evangelizing & development and now seems more interested in supporting the defacto Flash standard. This is probably their just being pragmatic as the Flash plugins have at least a magnitude greater market penetration then SVG support but it doesn't bode at all well for SVG.

    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

  • 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 [croczilla.com].

    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 corrupte
  • I remember that RIP [thebbs.org] 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?
  • ...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.

Slashdot Top Deals

The explanation requiring the fewest assumptions is the most likely to be correct. -- William of Occam

Close