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.
Post a Comment
Member since:
2005-07-21
Fans: 0
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.
Member since:
2005-06-29
Fans: 0
Member since:
2005-07-11
Fans: 0
Member since:
2005-10-11
Fans: 0
Member since:2005-10-12
Fans: 0
Member since:2006-01-03
Fans: 0
Member since:2005-07-13
Fans: 16
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.
Member since:
2006-06-19
Fans: 4
KDE4 should be awesome. I am back to preferring gnome again but nothing wrong with KDE.Member since:
2006-07-03
Fans: 0
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...
RE[3]: That's great
Member since:2006-05-28
Fans: 0
Member since:
2006-07-03
Fans: 0
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
Member since:
2005-07-06
Fans: 0
Member since:2005-07-06
Fans: 19
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?
Member since:2005-07-07
Fans: 3
Member since:
2006-02-05
Fans: 0
Member since:
2005-07-06
Fans: 0
Member since:
2005-09-08
Fans: 0
Member since:
2005-09-19
Fans: 0
Member since:2005-08-06
Fans: 0
Member since:
2005-09-19
Fans: 0
Member since:
2005-07-07
Fans: 3
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.
Member since:2005-07-29
Fans: 1
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.
Member since:
2005-07-07
Fans: 3
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.