Last week Trolltech announced the release of a technology preview of Qt 4.2, the upcoming version of the cross-platform toolkit scheduled for the 4th quarter of 2006. This release features a new framework for handling canvas items (Graphics View) and improved support for desktop integration, including dbus bindings, Glib eventloop support, switchable button order and a Clearlooks-like style.
Qt 4.2 Technical Preview Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Which version of Qt are they targetting for the release of KDE 4.0? IMHO they should target the very most update to date one at the time of release just to prevent deprecated stuff getting into the codebase which they would later have to maintain for backwards compatibility.
From what I read, kdelibs is supposed to require Qt 4.2 (which means they will require the as-of-yet-as-preview version).
The development version of kdelibs already requires QT 4.2 TP so it will probably be the minimum requirement for KDE 4.0 too.
Yes, it is great to build something with such a wonderfull team and software. KDE4 will be something huge, at least I hope so !
I hope it woun’t be huge – we don’t need bloat
I hope it will be fast, clean, easy and ergonomic.
I hope it will be fast,
From what I’ve seen in following the dev blogs through planetkde, the ports to Qt 4.x are showing performance improvements without resource baggage, in some cases with reduced resources. So KDE 4 should be notably faster than 3.5.x.
clean, easy and ergonomic.
That of course is in the eye of the beholder, but the tear-down/re-build approach they’re taking combined with the creation of usability teams, plasma etc. should lead to significant improvements across the board here as well.
ergonomic like my insoles or my mouse
KDE4 should be awesome. I am back to preferring gnome again but nothing wrong with KDE.
bloat here, bloat there, bloat is everywhere. Do you people really have to meantion bloat in every news that appears here ??? And what the f*** is bloat in your opinion ? It drives me crazy when I have to read yelling about bloat. Specify me one place where the bloat is when there is no even RC candidate…
Actually, I think you’d be hard-pressed to call Ion bloated.
http://www.modeemi.fi/~tuomov/ion/
In fairness to bosco_bearbank, he just implied that huge equates to bloat. He did not suggest KDE4 would indeed be bloated, he just expressed that he hoped it wouldn’t. I don’t think he was yelling either
Does ION use QT ? Is it a DE that uses QT? And does it actually have anything to do with this news ?
DE’s will always be bloated in your opinion, because there will be apps/code that’s not suited for your needs and you will never use them, but others will. It’s one of their main tasks to be bloated
Their purpose is to provide FULL environment and to satisfy ALL the needs not only yours.
Edited 2006-07-03 23:39
This is a cut from Aron Seigo’s blog about qt 4.2 and KDE 4
“for me this marks a very important step, however, as it means both graphicsview and svg support is now publicly available to play with. these have been two blockers in plasma’s path.”
Depending on how much of the SVG is supported in Qt, the question one reaises is where ksvg falls into the equation; a while back the rumour was that the svg support in Qt would be very basic, and ksvg would extend support further, but with that being said, and Apple working on getting ksvg working with Safari, will Ksvg end up replicating alot of what Qt has already got?
afaik, the svg support on Qt is very fast, so more suitable for icons and other UI parts. ksvg will most likely be used for backgrounds and other bigger, more complex svg’s.
can’t wait for KDE4
I think I read in a blog that 4.2 was being used.
Yes, and Qt only implements the SVG Tiny subset which are suitable for icons and backgrounds (stuff that isn’t animated or require user interaction*). KSVG2 tries to implement everything, which includes javascripting. This will allow Flash like stuff.
What ever happened to the planned java bindings?
They’re coming. In fact if you read the blogs, they’ve even been demo’d in Trysil.
Excellent news on the Cleanlooks theme, switchable button order and QDesktopServices! These should make QT apps fit in much better on Gnome.
The print dialog also looks great.
All in all, it looks like 4.2 is going to be a really good release.
seems like most cross-desktop integration work comes from KDE and Qt. the Qt-gtk theme offers visual integration, there is a tool which makes Gnome apps use the KDE file dialogs, a project exists to make it easier for non-KDE apps to use KDE technologies, Qt apps can now use the glib eventloop (aRts even depended on glibc) and now Qt apps change their buttonorder and have a Gnome theme… I’d love to see some initatives from the ‘other’ side.
I’d love to see some initatives from the ‘other’ side.
GTK+ 2.6 added support to change the button order within GTK+ dialogs. See:
http://developer.gnome.org/doc/API/2.0/gtk/GtkDialog.html#id3089837
It’s up to the individual apps to take advantage of this, but GTK+ currently has the support necessary for KDE/Win32-style button ordering.
so the apps still have to do some work themselves (so most won’t support it)? doesn’t sound really convincing, tough it’s a step. Wouldn’t it be usefull if gnome developed a wrapper which makes this (and probably other stuff) easier for app dev’s, so they use it? This is how KDE seems to be handling such stuff, and it pays off… faster development and more consistency would be worth the effort, i guess.