Qt 4.5 to Dramatically Improve QtWebKit and QGraphicsView Through Animations and Speed Ups

Sunday, 10 August 2008 | Skuegler

At Akademy 2008 in Belgium, Qt developers Simon Hausmann and Andreas Aardal Hanssen announced dramatic improvements in the web browser engine in Qt and the canvas that is used by, for example, the Plasma desktop shell. Video support, animations and transitions, optimisations to speed up painting and animations, and new graphical effects open up nearly endless new possibilities for developers to present their user interfaces with. Read on for more details.

Reflecting a video in QtWebKit

Hausmann demonstrated a WebKit based Konqueror web browser displaying video content through the HTML 5 video tag. With only one line of HTML code, video content in Ogg format can be embedded in webpages. Style elements can then display reflections of this video widget. Naturally, the underlying multimedia engine used in QtWebKit for showing video content is KDE's Phonon multimedia layer. Animations will also be possible. By adding simple CSS properties to your webpage elements, you can animate, rotate and fade those elements. Writing rich and animated webpages and of course embedded web content in applications becomes a breeze with QtWebkit.

After Simon's demo of QtWebkit, Andreas Aardal Hanssen entered the stage to show some of the improvements that will be in Qt 4.5 which will be released later this year or in early 2009. After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma, more breakthroughs in the development of Qt's graphics canvas are coming up. Speed-ups of up to 40 times faster in some cases go along with a set of really nice additions that are unparalleled in today's toolkits and can only be dreamt of in competing offerings. Improvements that will be available in Qt 4.5 include:

Transition animations in user interfaces
Optimisations in painting operations
They are also looking into extensive support for animations through a new animation API, due for an unspecified future Qt version. Graphical effects like blur, bloom, shadow and opacity for items on the GraphicsView are being looked into as well.

Hausmann's and Hanssen's future plans for those components in Qt have been met enthusiastically by the KDE developers. Soon, these new features and optimisations will be available to KDE users around the Free world.

Comments:

Benchmarks?b - Beat Wolf - 2008-08-10

are there any benchmarks? does it partialy solve the nvidia problem? etc

Re: Benchmarks?b - Xanadu - 2008-08-10

That was my first thought as well. The nVidia part, that is. I hope so. I personally have only used KDE4* on Live CDs since KDE4* isn't ready for "me", yet (yes, I like *real* icons on the desktop, and a hideable "kicker"). I was going to jump to 4.1 because, well, I really want to, but the nVidia problems have kept me at bay hoping that by 4.2, nVidia will have gotten their act back together enough. If these performance boots help make KDE4* on nVidia cards much less painless, then I can work around some of the other limitations of KDE4 until they are implemented.

Re: Benchmarks?b - Pinaraf - 2008-08-10

Why should the KDE or Qt guys fix nvidia bugs ? nVidia recognizes that it's their fault and will release a drivers fixing these bugs, but it's not a KDE or a Qt problem when the vesa driver is faster than the nvidia proprietary driver.

Re: Benchmarks?b - Beat Wolf - 2008-08-10

well, my question was actualy if the speedup makes up somewhat for the nvidia slowdown. but i forgott that the new driver will probably be out before i got a kde 4 with qt 4.5

Re: Benchmarks?b - Xanadu - 2008-08-11

I wasn't suggesting that TrollTech or KDE Devs somehow become nVidia gurus and fix their busted module. I was more asking if these tweaks that have been made make life easier for us nVidia users. I'm not nieve enough to thing that TT/KDE is somehow responsible for nVidia screw ups.

Re: Benchmarks?b - Sebastian Kuegler - 2008-08-11

We hope confidently that the nvidia issues are solved *before* 4.5 ships. Qt 4.5 might make some things on nvidia faster, but it's really general optimizations, not nvidia-specific ones. All users should benefit from those optmizations, since they for example improve clipping on graphicsview.

Re: Benchmarks?b - Ménard Alexis - 2008-08-11

Nvidia's problem are more OpenGl oriented so the Nvidia problem can only be fixed by Nvidia. QGV doesn't use Graphics Acceleration.

Re: Benchmarks?b - ac - 2008-08-11

nvidias opengl driver is fine. their 2d acceleration isn't working with qt4. and graphicsview can actually use opengl for rendering.

Re: Benchmarks?b - Michael "tactless" Howell - 2008-08-12

NVidia's 3D drivers are among the best. NVidia's 2D drivers suck. All 2D is a bit slow, but it is usually not very noticeable. Qt4 amplifies the inefficiency by making heavy use of 2D acceleration.

Mmm hmm. That's nice. - charlie - 2008-08-10

Should have been here about 10 years ago. I know some SMIL 2.0(HTML+Time 2) and these years waiting for these type of things to go mainstream have made me indifferent. By the way, how old is Adobe's SVG viewer that has 1.0 capabilities? And SVG 1.0 is still not fully available on the 'cool' browser today. The third world war will probably arrive by the time developers get their acts...oh never mind...what's the point.

Re: Mmm hmm. That's nice. - Lisz - 2008-08-11

Adobe gave up on their SVG plugin since they bought Macromedia Flash. What else could we expect from them... http://www.adobe.com/svg/eol.html Hopefully Firefox is going to make their svg viewer usable on IE (same with canvas and JS2.0).

Re: Mmm hmm. That's nice. - Iuri Fiedoruk - 2008-08-11

>>Hopefully Firefox is going to make their svg viewer usable on IE (same with canvas and JS2.0). Huh? Can you please elaborate? Is there any truth on that or is just a wish?

Re: Mmm hmm. That's nice. - a-non-a-moose - 2008-08-13

Uh... What? That statement made no sense. On so many levels. 1) It's not like it's a plugin or something. It's integrated into gecko's rendering engine 2) Why would gecko devs care anything about IE? 3) IE sh!ts it's pants whenever it is handed XML anyway. (SVG is just an XML namespace)

Re: Mmm hmm. That's nice. - Michael "I'm sorry" Howell - 2008-08-12

I can tell you mean well, but your statement comes off as being very trollish. Trying to explain in a simple way: IE sucks and it's in M$'s best interests NOT to add cool non-proprietary stuff to IE. There isn't as much motivation to work on SVG and friends because mainstream web can't use it. If IE wasn't the mainstream browser web page authors would be free to use those features, and developers would have more reason to work on them.

Re: Mmm hmm. That's nice. - Kaiwai - 2008-08-13

Ah, how is it a 'troll' when the reality is that the SVG implementation in Firefox is not 100% complete; may I suggest you look at the latest info on it, and you'll find that large chunks of the SVG specification haven't been implemented yet. All very nice to rave about how great a feature is, but pointless if it isn't implemented properly.

typo - richlv - 2008-08-10

there's a typo where a sentence is split in two : "After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma. More breakthroughs in the development of Qt's graphics canvas are coming up." should be a single sentence, .->, and M->m

Re: typo - NabLa - 2008-08-11

You are wrong.

Re: typo - J. M. - 2008-08-11

I think he's right.

Re: typo - PurplePerson - 2008-08-12

He's right, but the resulting sentence after the change isn't exactly pretty either... really not pretty.

Re: typo - Marc Driftmeyer - 2008-08-13

"After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma. More breakthroughs in the development of Qt's graphics canvas are coming up." This is fine, but to be succinct and proper with English Grammar: ``After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma--more breakthroughs in the development of Qt's graphics canvas are coming up.'' In LaTeX terminology there should be a \textemdash for the ``dash'' whose purpose is to emphasize interruptions in sentences by: 1. to emphasize explanations, including appositives, examples, and definitions; 2. to emphasize a contrast; 3. to emphasize an ``aside''; or 4. to show hesitating or broken-off speech

Too bad - Lisz - 2008-08-10

Too bad KDE 4.2 will not be based on Qt 4.5, that means we'll have to wait for KDE 4.3 to have a good web experience using Qt/KDE technologies (KHTML is not good enough unfortunately).

Re: Too bad - T. J. Brumfield - 2008-08-10

Aren't there QT 4.5 preview packages available right now? And don't they include a basic QT/Webkit browser?

Re: Too bad - Ian Monroe - 2008-08-11

We're on a 6 month release cycle though, KDE 4.3 will be released pretty soon after Qt 4.5.

Re: Too bad - Marc Driftmeyer - 2008-08-13

You mean July 2009.

Re: Too bad - Sebastian Kuegler - 2008-08-11

As far as I know, no decision wether to depend on Qt 4.5 has been taken, so you're "Too bad ..." is a bit premature.

Re: Too bad - Lisz - 2008-08-11

> you're "Too bad ..." it's "your "Too bad..."" and kde4.2 will be based on Qt4.5, it's been said on the ML.

Re: Too bad - Ian Monroe - 2008-08-11

Ha yea, I was confused. Right, I don't see why KDE 4.3 wouldn't be based on Qt 4.5...

Re: Too bad - Ben Morris - 2008-08-11

Will the performance-enhancing improvements introduce incompatible API changes? Will it be possible to get some of the performance improvements by building KDE against Qt 4.5, even if it doesn't actually require it?

Re: Too bad - Kit - 2008-08-11

From reading the blog where the Troll mentioned the 40x improvement it *sounds* like it doesn't require changes to the applications, so I think (at least that change) could be gotten for free just by upgrading your copy of Qt. Even if it requires a change it probably won't be too big, and if it would have a large impact the distros could ship a patched version of KDE with a 4.5 dependency. (mind you, I'm just guessing based on the wording in the blog)

Re: Too bad - Erunno - 2008-08-11

As far as I know Qt has strict API and ABI policies for forward compatibility so any application written with Qt 4.x should be compatible with Qt 4.y where y > x for the whole life cycle of the Qt 4 series.

Re: Too bad - Mark Hannessen - 2008-08-12

Not doing so would mean shooting themselves very hard in their commercial foot... something they probably won't enjoy.

Re: Too bad - Michael "wait!" Howell - 2008-08-12

KDE4.0 could easily be built against 4.1, and get many of the improvements (performance stuff, bugfixes, etc). KDE4.1, if built against Qt4.5, would get the performance and WebKit improvements without any source modifications. Even if KDE4.2 isn't dependent on Qt4.5, you can always compile against it and get the improvements.

Re: Too bad - yoda - 2008-08-13

You don't need to recompile. Just install the new Qt libs.

Omg! Omg! - superfan! - 2008-08-10

I can't believe my eyes!!! A new animation API too !! That was what I was waiting for :D Please please, post the talks online, some timings, git references or whatever. I need more!! ;-)

Use of Qt in Mozilla - Parminder Ramesh - 2008-08-10

Great work peeps! Now I'm sure most of you have heard that a port of Mozilla 1.9 (and Firefox 3) to Qt 4 is underway. On one of the developers' blogs (http://blog.vlad1.com/2008/05/06/well-isnt-that-qt/), he notes that while Qt is a well-designed modern toolkit, it has a few quirks: *He notes that a drawGlyphs method on QPainter something that would take a QFont and an array of glyphs and positions - is missing; *QPainter cant do arbitrary path clipping with antialiasing *Cairo has a few optimizations (e.g. with paths) that QPainter doesn't. Will these quirks be addressed in upcoming Qt releases? It would be awesome to have a better-integrated Firefox (Konqueror is great too, but just doesn't offer the same array of extensions). Thanks!

Re: Use of Qt in Mozilla - Sebastian Kuegler - 2008-08-11

Actually, having Firefox do its rendering via Qt has little to do with integration. Integration of the webbrowser is about a bookmark system, shared proxy settings, mimetype settings, certificate integration with KIO, password integration with kwallet and of course things like file dialogs from KDE. Using Qt as rendering engine is just one step.

Re: Use of Qt in Mozilla - T. J. Brumfield - 2008-08-11

File dialogs is the killer thing for me. I can't stand the damned GTK file dialogs. And yet I really love Firefox. And I think on openSUSE which I've been using lately, I set proxy settings in KDE, and Firefox recognizes them. There is an option in Firefox (it may be an openSUSE patch) to recognize system proxy settings. Web browsers often have separate mime settings from the rest of the system, because you either open it as a plugin, save the file, or pass it to an app. It is more than just saying app x is related to that file. kioslave and kwallet integration would be nice, but frankly Firefox stores passwords well enough on its own, where as I find the kwallet pop-ups to be a little annoying.

Re: Use of Qt in Mozilla - André - 2008-08-11

There is a hack around that makes a lot of GTK applications use the Qt dialogs instead. Works pretty well, and makes GTK apps play a bit nicer in your Qt environment. Of course, don't expect KIO tricks to works all of a sudden.

Re: Use of Qt in Mozilla - ac - 2008-08-12

How nice of you not to mention what it's called. Just that it exists... buhuuu!

Re: Use of Qt in Mozilla - Emmanuel Lepage Vallée - 2008-08-12

http://kde-look.org/content/show.php/KGtk+(Use+KDE+Dialogs+in+Gtk+Apps)?content=36077

Re: Use of Qt in Mozilla - André - 2008-08-12

Sorry, yes. I did not have time at that point to look it up. See it as an exercise to hone your Google skills ;-)

Re: Use of Qt in Mozilla - Michael "GTK file dialogs" Howell - 2008-08-12

I can't imagine a Qt firefox using a Gtk file dialog, could you ;). Actually, I'd expect it to use the standard QFileDialog. While it's not as awful as the GTK one, it isn't KDE either. Of course you can always use KGtk or KQt, respectively.

Re: Use of Qt in Mozilla - Jonathan Thomas - 2008-08-12

I've used the latest build and at this moment it does use the Qt file dialog as expected. It's total pre-alpha material and practically unusable for normal browsing, but it's still sorta cool.... (It also has a lot of potential!)

Re: Use of Qt in Mozilla - Stephan Sokolow - 2008-11-16

Always good to hear. I may be hopelessly addicted to KDE's application-specific file dialog bookmarks and I may be doing fairly well with KGTK, but it'll definitely be a step in the right direction to have native support for Qt file dialogs.

QtWebKit API - Kit - 2008-08-11

I could wait a few more days for the videos to be published (but whats the fun in that? :P), but did the talk cover anything about how the QtWebKit API is going to be extended? The main-snapshot documentation (on doc.trolltech.com) has already been extended to include QNetworkDiskCache but I haven't noticed anything about exposing the DOM (directly via the C++ API) or anything about NS plugin support in a while (I had heard that it was in the svn server upstream a while ago)? I'm also hoping there'll be more information about the new KJS implementation (Frostbyte, I think it was called?) and some of the other stuff going on in KHTML that I've seen blogs somewhat mentioning in the past. So far I've really enjoyed developing against QtWebKit (the trolls have done an outstanding job with the API so far!) and loved being a Konqueror+KHTML user for quite a while, both are very nice rendering engines and I hope we get to have both actively developed for a long time to come!

Re: QtWebKit API - Morty - 2008-08-11

Frostbyte went into SVN before KDE 4.1, http://www.kdedevelopers.org/node/3476

Re: QtWebKit API - manyoso - 2008-08-11

For netscape plugin support I can tell you that QtWebKit in trunk already has this support. And as for public API to control these plugins see this: http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=shortlog;h=adam/netscape-plugin-manager Also, squirrelfish is the name of the new JavaScript engine in WebKit. And yes, this will be included in the next version. I'm not sure that a public DOM API will be ready for the next version. It is a big undertaking and could dramatically increase the size of the public API. What's more, it is important to get it right.

Re: QtWebKit API - SadEagle - 2008-08-11

You won't see much information on KJS from aKademy since neither Harri nor myself are there; nor is the KHTML uber-guru Germain. ...And besides, being old-school KDE guys we're not big on PR and flashy demos anyway. The initial frostbyte version (-41.0) is indeed in 4.1.0, and I've tweaked a few things since then, though nothing major. I tend to work in a funny way where I spend a lot of time thinking over a design problem at odd times, then when I am I finally happy I go ahead and try stuff... Except even on small stuff I tend to sit on patches for a while since something is always bothering me. (e.g. stuff like better for ... in behavior on dense arrays and better handling of large object literals inspired by one of the posts by vandenoever). Wrt to KHTML stuff: the biggest thing in 4.1 would be contentEditable, though the command set is currently somewhat limited. For 4.2, an ultra-smart SoC student is working on picking up the SVG code from WebCore, and is trying to do so largely through a compatibility layer to keep things from diverging. Though, it is hard since we have a far more minimalistic design philosophy. Can't really give any big KHTML plans from myself, since I tend to just pick off areas which I think need work... Right now e.g. load events from iframes/objects are a bit wonky, though their behavior overall is a lot better after the big rework in 4.0...

Re: QtWebKit API - Whatever - 2008-08-12

<em>being old-school KDE guys we're not big on PR and flashy demos anyway</em> That tastes a bit odd: showing of a new feature once in a while or posting short blogs about current development has nothing to do with PR or "flashy" demos. It is another way of communcation with the users. There are several ways to communicate with users: e-mail, blogs, news, irc, bugzilla, surveys, and so on. Every project picks the set they think fits their style best. You didn't pick "web presence", ok - but putting it like "I'm too cool for company like PR" is just plain wrong, both things have nothing in common.

Re: QtWebKit API - True Grit - 2008-08-14

"That tastes a bit odd" Speaking of odd, he never said what you imply in your post, he just said he doesn't (often/ever) show up at those big akademy get togethers that KDE has, which is not the same as saying he doesn't talk to "users" at all (heck, he posted here didn't he?). Jeez, lighten up.

hidden developers? - blauzahl - 2008-08-14

> he posted here didn't he? A very good point. ;) Most developers I've talked to say they ignore dot comments these days because of all the flames. Incidentally, the khtml group is very active on irc. I guess they need to put out press releases too? That seems to be the way to work these days. Although anything they say will instantly get bogged down in flames. :P Further reason to hide. ;)

When is the "hideable panel" back? - r. l. - 2008-08-11

For want of a better place to put this, and so it gets any attention it can, I really need the "hideable panel", and cant really switch back to kde without it, so I'm using gnome for now, but I always used to use kde, and I REALLY like the new 4.1, but kinda-sorta-really-need that (configurable...) "hideable" thing happening...?? - (Great job though, everyone!)

Don't like KDE 4.x so I must use Gnome - T. J. Brumfield - 2008-08-11

I don't understand this. Why not just use KDE 3.5.x?

Re: Don't like KDE 4.x so I must use Gnome - Stephan Sokolow - 2008-11-16

Could be a[n] Ubuntu/Kubuntu user. Their packagers considered KDE 3.5 "antiquated" and dropped every KDE 3.5 component with a KDE 4.x equivalent as of Intrepid Ibex.

Re: When is the "hideable panel" back? - Lisz - 2008-08-11

"hidable panel" is the most annoying feature ever, I hope it never gets implemented so I never have to use a PC that uses this lame feature. It's just so annoying to see the panel appear and disappear all the time when I just want to use it.

Re: When is the "hideable panel" back? - Grósz Dániel - 2008-08-11

Some users like it. As long as you can turn it off, it's better to have it than not to. If you have to use a PC with it turned on, just turn it off and turn it on again when you leave (if you don't have your own user account).

Re: When is the "hideable panel" back? - Erunno - 2008-08-11

I'm sorry to derail this fine thread, but this argumentation is beyond retarded. First of all, no distribution I know turns on hideable panels by default. It's an option strictly for the people who feel that they want to use the panel occasionaly but need the extra screen space otherwise. Nobody "forces" you to use it other than yourself. Plus, can anybody get more self-centered by proclaiming that your special dislike for one feature should be forced onto a whole community of users, especially if it's not even a fringe case? Or you are just trolling and I should stop feeding you. :-/

Re: When is the "hideable panel" back? - Vide - 2008-08-11

He's obviously trolling but this is somehow what the "hiding panel complainers" deserve, cause they're doing so much ado for a feature used by a minority of users (and in NO WAY blocker for a KDE release).

well, that's my problem with KDE4.. - eMPee584 - 2008-08-13

a lot of 'features used by a minority of users' where cut and not reintroduced, especially the many things that made KDE3 so lovely for power users (f.e. interface short cuts saving two three clicks/key presses on every file action, compared to windows, packing the panel full of features without sacrificing a pixel to white space)... Not only that, but the strive to GUI-wise turn KDE4 into a Vista/Leopard hybrid (i.e. hiding 'complexity', removing configurability in favor of 'defaults that please 90% of the users') totally took the fun out of using it for me. And i really tried to like it, having installed from SVN since beta phase and regularily upping. But i do see no progress on winning back the hearts of power users, just bling hype, overstatement and complacency... (and yes, as soon as i have the time to do it, i will contribute patches.)

Re: well, that's my problem with KDE4.. - Anon. - 2008-08-13

"a lot of 'features used by a minority of users' where cut and not reintroduced" Yet.

Re: When is the "hideable panel" back? - reihal - 2008-08-11

It depends on how large your panel is and how you use it. It's the center of my universe, and it occupies about a fifth of my screen. No delay, of course.

Re: When is the "hideable panel" back? - Simon Edwards - 2008-08-11

I'm not a fan of the panel hiding feature, but one increasingly important use case for having a panel that can be hidden is on UMPCs like the Asus eeePC and the new crop of UMPCs. These machines have screen resolutions around 1024x600 and every pixel is precious. A hideable panel gives more extra vertical space, even if it might be a bit annoying. Tom-with-the-Acer-One here at akademy yesterday showed me his work-around for this problem. Remove the panel and add the k-menu and taskbar to the desktop itself at the bottom. Nice machine too, I've got one ordered for the wife. 8-) -- Simon

Re: When is the "hideable panel" back? - Janne - 2008-08-11

"I'm not a fan of the panel hiding feature, but one increasingly important use case for having a panel that can be hidden is on UMPCs like the Asus eeePC and the new crop of UMPCs. These machines have screen resolutions around 1024x600 and every pixel is precious." True. Another important feautre to have in those machines is the MacOS-type menubar. Instead of wasting space by having each app have a separate menubar, there would be just one universal menubar. If I were asked, the MacOS-menubar would be enabled by default in KDE: At least that would eliminate most of the "KDE is a copy of Windows!"-whining...

Re: When is the "hideable panel" back? - Kolla - 2008-08-13

Speaking of hiding menu bars - I have for years and years wanted to "reimplement" the AmigaOS menubar in KDE. Unlike the MacOS menubar that is constantly there, the AmigaOS menubar only pops up when you press the right mousebutton. While you have this mouse button pressed, you can move around in the menues, click entries, set and unset checkmarks with left mousebutton - and once you release the right mousebutton, all actions you have clicked will be executed, in the order you pressed - this is what we old amiga users call "multiselect in menues", and that noone else seem to have implemented - ever, sadly. I miss this very much in f.ex image processing programs that tend to have long and deep menues. For every action I have to wade through the menues over and over again, instead of just go once. Instead I want to go to menu, click blur, click resize, click save, let go of menu button, see it blur, resize popup coming up, enter new size, press OK, file saved, all done by going through menues only once. Anyways, a start would be to let KDE be able to hide panels, and assign hotkeys for them to pop up - my hotkey would ofcourse be the right mousebutton. This also brings me to another thing I miss - complete control over input modifiers, I want to define what happens when I click a file with certain modifier keys pressed, for example if I click a png I want it to open with kview (or other simple viewer), but if I click a png while holding down ALT-key, I want it to open in an editor, like f.ex gimp. To be able to define actions for click, double click and even tripple click would be most welcome - yes "most users" will never need them, I know. I hate "most users", they ruin it for the rest of us :P Likewice, I want to be able to define what drag&drop does with modifiers, f.ex I might want to drag&drop of image files while holding a key converts all files to pngs in the destination. I also miss the ability to assign certain commands to certain directories, so that if I f.ex have a directory with images (album), I can set it to open with kview instead of just opening it in the file browser (the default tool tooltype, for those who know amigaos) While I'm on this wishlist - it would be excellent to have the desktop and the default filebrowser (dolphin) act as one, ideally (IMO), the desktop itself should be dolphin.

Re: When is the "hideable panel" back? - Marc Driftmeyer - 2008-08-13

I prefer the NeXTSTEP Tear off menus that allow for saved state and auto change between applications while allowing for maximum Vertical Space..

Re: When is the "hideable panel" back? - r. l. - 2008-08-12

Thank you for the useful tip, (I am the one who started this whole conversation...!) I appreciate that. All the best!

Re: When is the "hideable panel" back? - r. l. - 2008-08-12

Oooops! I pressed the wrong "reply-to-this" button, Sorry! this comment was meant for the post above!

Re: When is the "hideable panel" back? - borker - 2008-08-11

this has been gone over a number of times already http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan

Corrections - Andreas Aardal Hanssen - 2008-08-11

First of all, very cool article. As I mentioned in this talk, 4.5 is going to be great. However I feel a minor correction is in place - we're researching animations, transitions, and effects, but these feature are not yet tied to any roadmap nor release target date (in the talk I believe I said "4.5, 4.6, 4.7, we'll see once we know more"). In any case, the future is looking very bright IMHO.

Re: Corrections - Jonathan Riddell - 2008-08-11

I've clarified this in the article now.

Does it scale down? - David Johnson - 2008-08-11

Qt is big on the embedded scene, where the hardware isn't necessarily this week's Dell XPS. Are there performance improvements for slower CPUs and low end video cards?