DEC
20
2005

Qt 4.1 Now Available

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.

Comments

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?


By Shyru at Tue, 2005/12/20 - 6:00am

most likely, yes.

:D


By superstoned at Tue, 2005/12/20 - 6:00am

Yes, KDE4 will require 4.1, parts of trunk already do :)

-Benjamin Meyer


By Benjamin Meyer at Wed, 2005/12/21 - 6:00am

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.


By AC at Thu, 2005/12/22 - 6:00am

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


By ac at Thu, 2005/12/22 - 6:00am

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.


By thomas at Tue, 2005/12/20 - 6:00am

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.


By Michael at Tue, 2005/12/20 - 6:00am

Furthermore, KSvg supports DOM which the Qt-svn does not (not needed for tinysvg-usecases)


By Carsten Niehaus at Tue, 2005/12/20 - 6:00am

ksvg provides manipulation of svg @ runtime with DOM , qt svg does not


By ch at Tue, 2005/12/20 - 6:00am

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 ?


By patcito at Tue, 2005/12/20 - 6:00am

http://www.croczilla.com/svg/samples/svgtetris

click on svg , konqui goes boom.

and no, i did not report it to bugs.kde


By eol at Wed, 2005/12/21 - 6:00am

that's because you're not using the yet to be released KSVG2. I was asking to people in the know.


By patcito at Thu, 2005/12/22 - 6:00am

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.


By AngryMike at Wed, 2005/12/21 - 6:00am

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:
http://www.xaraxtreme.org/news/11-10-05.html


By Vlad C. at Tue, 2005/12/20 - 6:00am

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


By James Richard Tyrer at Tue, 2005/12/20 - 6:00am

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.


By Iuri Fiedoruk at Tue, 2005/12/20 - 6:00am

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.


By ben at Tue, 2005/12/20 - 6:00am

we're talking about qt4, so that's bollocks.

cheers,
muesli


By Christian Muehlhaeuser at Tue, 2005/12/20 - 6:00am

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.


By 2rpi at Tue, 2005/12/20 - 6:00am

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


By patcito at Tue, 2005/12/20 - 6:00am

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.


By mikeyd at Tue, 2005/12/20 - 6:00am

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


By Marc Collin at Tue, 2005/12/20 - 6:00am

if your program slow is now, in future faster will it be. computer faster get all the time, any bad programmer will know.


By ac at Tue, 2005/12/20 - 6:00am

that could almost be a poem ;)


By Leo at Tue, 2005/12/20 - 6:00am

I think it's not a poem... it's Master Yoda ;-)


By Bardok at Wed, 2005/12/21 - 6:00am

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.


By mikeyd at Tue, 2005/12/20 - 6:00am

In my experience, even "hello world" in Java takes a few seconds to start up, even when compiled to native code with GCJ.


By rqosa at Wed, 2005/12/21 - 6:00am

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


By Michael Pyne at Tue, 2005/12/20 - 6:00am

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.


By Bryan Feeney at Wed, 2005/12/21 - 6:00am

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?


By Leo at Wed, 2005/12/21 - 6:00am

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.


By Bryan Feeney at Wed, 2005/12/21 - 6:00am

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


By Anonymous at Wed, 2005/12/21 - 6:00am

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


By ac at Wed, 2005/12/21 - 6:00am

> 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


By Anonymous at Wed, 2005/12/21 - 6:00am

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


By Aaron J. Seigo at Thu, 2005/12/22 - 6:00am

Qt on Windows and Mac acts as a wrapper around the native APIs. Shame on you!


By Flavio at Tue, 2005/12/20 - 6:00am

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:
http://blogs.msdn.com/oldnewthing/archive/2005/02/11/371042.aspx


By MORB at Tue, 2005/12/20 - 6:00am

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.


By blacksheep at Tue, 2005/12/20 - 6:00am

> KDE is kinda slow to startup

Not anymore :p
http://osnews.com/comment.php?news_id=13039


By ac at Tue, 2005/12/20 - 6:00am

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.


By Leo at Tue, 2005/12/20 - 6:00am

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.


By Anne-Marie Mahfouf at Tue, 2005/12/20 - 6:00am

I thought it was going to be released with 4.1 :( I suppose it'll come out with 4.2 right guys?, :)


By patcito at Tue, 2005/12/20 - 6:00am

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


By Shyru at Tue, 2005/12/20 - 6:00am

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


By patcito at Tue, 2005/12/20 - 6:00am


By Ian Monroe at Tue, 2005/12/20 - 6:00am

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


By Anonymous Coward at Tue, 2005/12/20 - 6:00am

It is open source already then. But its confusing: http://doc.trolltech.com/4.1/qtcanvas.html appears to have it named Q3Canvas.


By Ian Monroe at Tue, 2005/12/20 - 6:00am

What Trolltech mean by "commercial" is that it is for paying customors only, eg. not open source.


By Morten Sjøgren at Thu, 2005/12/22 - 6:00am

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!

:D


By Steve at Tue, 2005/12/20 - 6:00am

I would also like an built-in opensource SSL Socket, currently it is only in "Solutions" which is for their commercial customers only.


By Morten Sjøgren at Thu, 2005/12/22 - 6:00am

Pages