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.
Given the SVG and PDF capabilities of Qt 4.1 and all other improvements I hope that KDE 4 will require Qt 4.1 as minimum version. Will that happen?
most likely, yes.
Yes, KDE4 will require 4.1, parts of trunk already do :)
I hope so because 4.0 is buggy as hell! I hope they plan for 4.1.1 because even 4.1 isn't ready.
the difference between a troll and a user is that the user actually gives details when he says that something is buggy, crappy or whatever.
They suplement each other. qsvg only implements the tiny svg specification. So there is no duplication of efforts. ksvg tries to implement full svg support.
Furthermore, KSvg supports DOM which the Qt-svn does not (not needed for tinysvg-usecases)
ksvg provides manipulation of svg @ runtime with DOM , qt svg does not
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 ?
click on svg , konqui goes boom.
and no, i did not report it to bugs.kde
that's because you're not using the yet to be released KSVG2. I was asking to people in the know.
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?
So there will be overlap if QT wants to be 1.2 compliant.
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.
Here's the original announcement giving the reasons why they are releasing their product as open source:
> it will be way faster
Is that really what is most important?
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.
we're talking about qt4, so that's bollocks.
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.
It's Qt not QT! QT is a dirty codec used by a company that likes to calls it self an apple. Instead please use http://www.theora.org :)
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.
if you created java program who's slow is your fault, bad programmer
bad programmer often do long action in an event... that block the gui,
the solution is thread and the gui will be responsive
any good programmer know that
if your program slow is now, in future faster will it be. computer faster get all the time, any bad programmer will know.
that could almost be a poem ;)
I think it's not a poem... it's Master Yoda ;-)
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.
In my experience, even "hello world" in Java takes a few seconds to start up, even when compiled to native code with GCJ.
> Correct me if I am wrong but doesn't QT4 now do all of its own rendering?
Qt has always done its own rendering.
> If so isn't this at least responsible for part of the slowness of it?
Huh? Qt is hardly slow at drawing. Perhaps you're using a poorly programmed theme?
> Is there a choise in rendering engines for QT4 - native widgets or QT4
As muesli just pointed out, Qt uses native rendering on every platform. On Linux, Qt itself is "native" :)
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.
I feel that Qt4 is not faster as Qt3. If you turn on the fancy stuff, Qt4 is A LOT SLOWER than any other toolkit.
brought to you as an user feeling, not as a programmer with benchmarks...
>>brought to you as an user feeling
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?
> Since when do you users compile
compiled it for myself (not that hard) and tried the demos. I think the developer lying if they say it's faster. It's maybe faster to compile Qt4 apps. But that's useless for the "Suse" customers...
A faster GUI response from Qt4 based apps is A LOT more important than compile times.
Don't ever hope that KDE4 runs faster on my 500Mhz Laptop than KDE 3.4.x/3.5.x
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 on Windows and Mac acts as a wrapper around the native APIs. Shame on you!
Not using the native controls, and rendering/managing your own controls that looks like the original one is not a sin.
On windows, even microsoft does this because the native widget toolkit is crap, as this blog entry by Raymond Chen explains:
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.
> KDE is kinda slow to startup
Not anymore :p
Not in my experience.. And I use Qt mostly on Windows at the moment and can't see any difference to native apps (slightly longer start up times for trivial programs). Dunno about Mac.
How true is that :) I was always annoyed by the different menus(they have some offests) and Qt never used cleartype for font rendering so all the Qt apps on windows look alien.
I thought it was going to be released with 4.1 :( I suppose it'll come out with 4.2 right guys?, :)
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
>>QCanvas ported to Qt4-Style API will be available as a QtSolution
will it be open source?
>>Something new and equivalent to QCanvas will be available in Qt 4.2
sounds cool :)
http://doc.trolltech.com/4.1/porting4.html#qcanvas wasn't updated. :P
From the release to commercial customers
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.
I wonder if they'll opensource that one
It is open source already then. But its confusing: http://doc.trolltech.com/4.1/qtcanvas.html appears to have it named Q3Canvas.
What Trolltech mean by "commercial" is that it is for paying customors only, eg. not open source.
Since FTP and HTTP are supported natively within QT, I'd love to see a native SSH client available.
Trolltech if you're listening, please implement it!
I would also like an built-in opensource SSL Socket, currently it is only in "Solutions" which is for their commercial customers only.