Submitted by Trolltech has published a preview of Qt 4.4. “Qt 4.4 is one of the most exciting Qt releases ever, expanding the range of what is possible with Qt. While the release is still several months away, we would like to provide you with a sneak preview of several key new technologies set to be included in Qt 4.4.”
Didn’t I read about Mac OS X QT being rewritten to base off Cocoa instead of Carbon?
Thanks to Trolltech for a consistently superb frameworks.
Yeah you did, but they basically didn’t make the decision to rewrite to use Cocoa until the announcement that there would be no 64bit Carbon going forward. As that was just this summer IIRC I don’t think they had time to do that rewrite in time for 4.4, though I’d love to be wrong about that
http://labs.trolltech.com/blogs/2007/06/21/wwdc-qt-carbon-64-bit-an…
Edited 2007-12-20 00:57
yes, this is 4.5 material afaik.
not like 4.4 doesn’t come with enough cool stuff as it is: phonon, webkit, WoC (widgets-on-canvas), QtConcurrent, patternist (xml stuff), tons and tons of bug fixes ……
i mean, they *had* to leave *something* for 4.5, right?
Correct, we are aiming to have a port of Qt written in Cocoa ready for Qt 4.5.
Thank you for the kind words!
when will the 4.4 release be integrated with KDE4?
Will KDE4.0 be built on Qt4.4 or will they stay with an older release.
Given that new KDE technologies such as phonon are in this new Qt release I would expect it to be used in KDE4 fairly well straight away (once it is officially released).
Anyone have more info?
> when will the 4.4 release be integrated with KDE4?
KDE 4.0 is being developed against Qt 4.3 as it is due for release in January, and 4.4 is not expected until the end of Q1 2008. KDE 4 applications developed against 4.3 should work with Qt 4.4 libraries without any source code changes or recompilation since Qt releases are binary compatible during their life-time.
There isn’t any “integration” required, so to speak.
Yes but for how long will KDE be “handicapped” by Qt 4.3 ? I mean it seems that it would be best if they used what the Qt provides instead of maintaining their own.
KDE does not and never has maintained their own version of Qt.
KDE 4.0 will use Qt4.3 because this is the version available at this time.
Since Qt4.4 will be available when releasing KDE 4.1, features developed for 4.1 can obviously make use of any new features available in Qt4.4
On the wekit side, the default html engine in KDE4.0 is still khmtl and it is (trying to come up with a nice, non-inflammatory word here) undecided whether or not there will be an eventual switch to webkit from khtml.
As far as the phonon development is concerned trolltech (to their great credit) are contributing directly into the KDE svn tree rather than maintaining their own phonon branch, so KDE already has all of their work in that area available to them (and visa versa of course).
So, of all the other goodness, a fair percentage doesn’t really have a KDE implementation so there won’t really have to be a point where they stop developing their own code and switch over to TTs or try and maintain parallel branches or anything.
I read somewhere about double-buffered refreshing in qt 4.4, for a flicker free resize by dragging window handles, and also within the window itself. I’m looking forward to it!
Yes, this is the “Alien widget integration” discussed in
http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the…
Garbage collection! Qt should should use Boehm’s gc to provide the best programming experience!
Please correct me if I’m wrong because I don’t really know much about this (and would like to) but:
Can’t you just use Boehm’s gc by yourself in your app ? Does the framework need to support it anyhow ?
I’ve been thinking in trying libgc with Gtk+ and I think the answer wouldn’t be that different so, that’s why I’m asking.
All QObject-derived class instances are automatically deleted when their parent object is destroyed. You mostly don’t need to worry about garbage collection.
to what the development community can do with the ‘sexy’ bits of the new Qt version. A simple, ubiquitous multimedia API and html engine are very powerful components and will make a lot of previously hard things quite simple going forward. Good times ahead