Trolltech has released Qt 4.1. The first feature release since Qt 4.0 includes new features which will make it into KDE 4 such as integrated support for rendering scalable vector graphics (SVG) drawings and animations, a PDF backend to the Qt printing system and a lightweight unit testing framework. Qt Designer has been updated, OpenGL support has been improved and SOCKS5 support has been added. Their 4.1.0 changes file has the full details. Get your copy from the X11 download page or from qt-copy in KDE's SVN.

http://svg.kde.org/
Did ksvg had any influence on the svg implementation of Qt? Do we now have two different svg renderers? Ksvg supports javascript, afaik. Which one will be used? SVG wallpapers and svg icons are rendered with ksvg atm.

So if I get it right, KDE4 will use QtSVG for things like icons rendering and it will use KSVG for rendering svg embeded in webpages and more complex tasks like that. By the way is KSVG2 able to render that kind of stuff http://www.croczilla.com/svg/samples/svgtetris ?

If QT does not support the DOM interface then they can't be considered 1.2 compliant. (Since 1.2, is in last call it seems no one can be 1.2 compliant right now, but I degress... :) ) SVGT does have a microdom that can be used for dynamic updates and scripting. Any word on when this will be done?

I've got a feeling that once Xara Xtreme (http://www.xaraxtreme.org/) is released under the GPL, it will be way faster (http://www.xaraxtreme.org/about/#performance) than any existing free software SVG implementation such as Inkscape, QT SVG, KSVG, Cairo, etc. I would suggest QT or KDE devs working on SVG to try to incorporate as much of Xara Xtreme's code as possible, because they're likely to be the best in the field.

IMHO, it is more important that SVGs be rendered correctly. With that as the goal, then Batik (Apache) would be the best choice. Yes, I know it is Java, but isn't GCJ 4.1 supposed to be able to compile Java classes to be used with C++?

IAC, what we could really use is Gaussian Blur filters -- icons look stupid without drop shadows.

I've started using qt4 this year, and I belive it's the best open-source toolkit out there, I can't even imagine why some people still use things as wxwindows and gtk.. well maybe because they don't wnat to create GPL apps, shame on them.

because wxWidgets (as it's called now) is truly cross-platform, making use of true native widgets, as opposed to just painting fake ones that look like the real ones. If your app is supposed to run on other platforms than linux, then you'll see a big difference in performance.

I am a big QT fan, but I think you hit on something here,as far as QT4 needing native widget support. Correct me if I am wrong but doesn't QT4 now do all of its own rendering. If so isn't this at least responsible for part of the slowness of it. Java did this with Swing which made it very slow and even more unusable.

IS there a choise in rendering engines for QT4 - native widgets or QT4 ?

And if QT offers its own rendering engine why not use openGL and take advantage of the GPU found in almost every mother board. This would allow for really beautiful shading and lighting with virtually no rendering penalities.

Java did this with Swing which made it very slow and even more unusable.

It made Java slow and unusable because Java is interpreted. (Yeah, I know, JIT, fast as native performance, you have benchmarks, yada yada. Bollocks.) C++ is natively compiled, so there's no reason at all for the speed of Qt rendering to be any different from native - provided your C++ compiler is up to scratch, that is.

Every java program I have used has been horribly slow. Every one. The gui isn't blocked, it's still there if you obscure and reveal it, it's just taking ages to respond to anything because it's flipping slow.

Actually, from what I've heard, the native-looking Qt themes defer to the native implementation where possible, and only render widgets themselves when necessary due to their configuration. This was necessary to get a decent look and feel for Mac OS X (added in 3.2) and in Windows XP.

Qt is certainly not slow, and in fact, neither is Swing (it's faster than SWT on a lot of benchmarks). The problem with Java apps is the high memory usage and slow start-up time caused by the JVM loading. Assuming it's coded correctly (a big assumption) Java applications are very responsive. Try the ThinkFree Office demo, of the DbVisualizer demo, for examples of how good Java can be.

Qt also supports rendering using OpenGL as of version 4: this is the "Arthur" rendering engine. If offers all you want, people just need to write a theme to take advantage of it.

Just tried ThinkFree office. It's very snappy indeed. So the question is, is every other Java developer retarded? If it is possible to make snappy user interfaces, what's up with every other high-profile java app on the planet? Eclipse, Azureus, both laggy on my system. So are they programmed by idiots or what's the difference here?

Eclipse is laggy because it has so much to do. I use Delphi 2005 at work, and if I didn't have 1GB of memory it would crumble. As for Azeurus, I've never actually tried it, so I don't know, but I've tried RSSOwl (a Java/SWT app) and it was perfectly responsive.

As for the skills of Java developers, Sun never explained in its documentation the necessity of multi-threading when developing Java GUIs. The SwingWorker class (which made it easier to multi-thread the response to GUI events) was never bundled with the JDK, even though it's been around since 1.1. So the answer is, Sun just never advertised the fact that it was necessary. It has started to do that now, though; there's a lot of momentum building behind Java on the Desktop again, and there are lots of little things like Foxtrot, SwixML and SwingML to make desktop development easier (not to mention the excellent GUI designer in Netbeans 5, the beta of which is available now).

The fact is Java still requires huge amounts of RAM: if you can manage that, Java will run beautifully. Sun realises this, however, and Java 6 should improve startup time and memory-use significantly.

Since when do you users compile (and have feelings *evil grin*)? Are you saying the developers are lying? Because if some developers say it is faster and you say it is not, their lying promotion would be my simple conclusion. You honestly believe they are lying to you?

what aspects of "GUI response" are you talking about exactly?
are you talking about painting N widgets of various types? or model/view based interfaces? or alpha blending and transparency (and if so, client side or hardware accelerated)? or ...?

Qt supports Windows and MacOSX native widgets when running on those operating systems. In X11, it draws their own widgets because there is no real native toolkit. Only version 1 would try to fake Windows theme (that theme is still available today), but those days are over.

Qt is truly cross-platform and performs very well (KDE is kinda slow to startup and stuff, but that has to do with all the technology behind it). Keep the FUD for yourself please.

QCanvas ported to Qt4-Style API will be available as a QtSolution.
QCanvas as in Qt3 is in Qt3Support and is somewhat buggy and slow.
Something new and equivalent to QCanvas will be available in Qt 4.2

*********************
QtCanvas Now Available
----------------------
The Qt 3 Canvas class has been ported to Qt 4.x, and does not depend
on any Qt3Support classes. The renamed QtCanvas is ideally suited for
customers who wish to port their QCanvas-based applications from Qt 3
to Qt 4 without relying on Qt3Support. QtCanvas is now available to
all Qt Desktop license holders.
*********************