Slashdot Mirror

← Back to Stories (view on slashdot.org)

KDE To Adopt SVG: Take A Glance

Posted by timothy on 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."

7 of 286 comments (clear)

  1. Re:Why ECMAScript? Choose Python! by Anonymous Coward · · Score: 1, Insightful

    Python? How silly!

    Ruby is the best language to use! Down with Python, up with Ruby!

  2. Could be great by Anonymous Coward · · Score: 1, Insightful

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

  3. Wicked cool! by GrouchoMarx · · Score: 3, Insightful

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

    --

    --GrouchoMarx
    Card-carrying member of the EFF, FSF, and ACLU. Are you?

  4. SVG != resolution-independent icons by mangu · · Score: 2, Insightful

    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.

    1. Re:SVG != resolution-independent icons by stienman · · Score: 3, Insightful

      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

  5. Re:Why ECMAScript? Choose Python! by Jondo · · Score: 2, Insightful

    Ridiculous? I think not. Have you ever actually seen SVG document that includes embedded Python? The KSVG team hooked in ECMAScript for the simple reason that it is actually used in real SVG's from the wild. IIRC Adobe's SVG impl. also does javascript, for the same reason.

  6. Not necessarily by Anonymous Coward · · Score: 1, Insightful
    Wouldn't rendering everything by SVG just make it worse?

    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.