Another Kernel Cousin KDE has arrived! Issue 28 covers mouse gestures in Konq/E, SVG support for KDE, Norwegian verbs, another KDE2+3 howto, and other exciting events in the world of KDE development. KDE 3 Beta1 is on its way, but that doesn't seem to stop developers from coming up with interesting ideas for the future of your favourite desktop!

I dunno, Niko and Rob have done a great deal the last few weeks. While we where busy yammering on the lists, they have been codeing their brains out.

Niko and Rob are not provideing screen captures though, mainly because they are too busy adding features. I think in the last two weeks they passed three more tests. Check out KSvg from kdenonbeta, it may not be the endall be all SVG viewer but it really is on the road.

-ian reinhart geiser
p.s. didnt someone say that we could have SVG support in icons allready because QT supported static SVG?

When QT3 came out and the docs said it could load and display SVG files, I wrote a quick test program just to see how well it worked. Well, most SVG files didn't even load. I can't recall what the trouble was, but it had to do with DOCTYPE -- so I muddled with the parts of the files that made the XML parser angry, and it worked -- *but* the output was crappy as hell. Fills were wrong, and the display wasn't antialiased. Of course, there are dirty ways around antialiasing, like oversampling, but it seems to the the GNOME guys, with their (beautiful) gnome_canvas, have the right idea.

Go competition!

(That's why I like that Linux has more than one desktop, even though I prefer KDE)

Qt's SVG support was rudamentary. That's why ksvg was written. If SVG becomes a major standard (which it hasn't yet, mainly because of lack of many windows apps using it), then you can expect more SVG support in Qt. This is how PNG/MNG was put into Qt as well. The first support was there because people wanted it, but now after it's fairly commonly used, it's absolutley great.

I was writing a vector graphics api for BeOS last year (http://home.earthlink.net/~zakariya/vector_api.html); but when I saw libart and another project, Zodius (http://www.tinic.net), I realized other folks had already done it, and better. Sigh. Well, I've attached a snapshot from that project. If any of you KSVG folks want me to lend a hand, I'd be happy to! (But I confess I'm rather busy on robotics stuff right now)

I'm sure it could be done, as libart doesn't depend on glib, gtk, or gdk...

but the question now is why? a lot of what is needed from libart is already implemented in ksvg. somethings are not in ksvg that are in libart, like
MicroTile Arrays, but then again, that's not needed :)

and from my prior experience with libart's source, I can tell you that it's pretty messy. that's mainly because 95% of the code hasn't been revised at all in over two years. on the other hand, libart works :)

Libart does support anti aliasing though, which would be a nice thing to have with vector graphics. I don't think that ksvg does AA at the moment. Perhaps they could write a wrapper round the library so if/when someone cleans the code up, they wont be affected too much.

librsvg uses gdk stuff extensively and is written in C. i don't think grabbing a bunch of stuff from librsvg would have done much good since probably all they would've been able to salvage would have been the parsing bits, which are the trivial parts (as opposed to the actual drawing)

as one would expect, ksvg integrates with kde well. it includes a konqueror plugin and uses Qt where appropriate. also, Niko and Rob probably Just Wanted To Do It. ksvg already passes a lot of the SVG tests and contains ~16k LOC. that ain't bad.

the svg problems in Qt talked about in that thread were one of the primary reasons why ksvg was started. the thread you linked to is over a month old and since then ksvg has improved quite a bit, surpassing the Qt svg support.

it would have been much more interesting (and worrying) to link to the threads that talked about the rather advanced font rendering required by SVG and how far along the people from the batik project figure ksvg is.

I think the ksvg project is wonderful. But are you sure it is suited for icon loading? To me it looks optimized for completeness (in terms of the API as well as in features) , which sounds just right for say usage in a browser or even a vector drawing app. But I think for icon loading performance and low memory consumption counts more. I wish there would be an easy pattern allowing to cache svg data for icons.

That's why we are also implementing an icon server that does intelligent caching based upon the file type. ksvg has an acceptable speed, but there are still a few optimizations needed to be done. Note that any complicated vector format where many calculations need to be done.

Isn't there a kgesticure for kde, I've tried it. It's nice, but difficult to make a good gesture.
You have to repeate a "M" three times to save it, and that isn't easy. But it's good and needs more work on it.

This could be integreated in kde, and then also in konqueror, koffice and k... Maybe in 3.1, or 3.2.
Im thinking about Koffice --> draw a "b" for bold, "I" and "I" again for Import an Image...

But QT 3.0.1 is out now, so beta 1 should come out pretty soon now, shouldn't it?

On an only slightly related note, I see lots of good improvements in QT 3.0.1, most notably in QFont:

X11 only: improved line width calculation. Fixed off by one error in interpreting Xft font extents. Allow the use of both Xft and non Xft fonts in the same application. Make sure fonts are antialiased by default when using xftfreetype.

Does this mean AA works in KDE 3.0 now? Does this also mean we can finally use all of the fonts installed on our system instead of only the ones that XRender finds? It sounds promising!

Yes, antialiasing now seems to work properly as do fonts and font selecting widgets (thanks to some KDE hackery done by Waldo and some adjustments in Qt). But for some reasons some programs don't draw all entries in the menu bar since pre Qt 3.0.1 times but I am not sure wether this is a QToolBar problem or rather a problem with the KDE classes.