We released the first version of the animation framework quite some time ago and I guess lots of you have been wondering what we were doing. Well we’ve spent that time improving the API and make it work seamlessly.

So now we’re proud to present you the Qt Animation Framework version 2.

What’s new:
* we removed the QtState and QtTransition we had previously and replaced them with the newer and much more powerful State Machine Framework Kent blogged about a few days ago.
* the animation groups allows you to run animations in sequence or in parallel. They now are 2 distinct subclasses (QtParallelAnimationGroup and QtSequentialAnimationGroup). This allows for more specific API to each of the class.
* the animations were previously all done through QtAnimation and the support for QGraphicsItem was, let’s be honest, hacked into it. Now we have added QtPropertyAnimation that adds support for QObject’s property feature. We killed the explicit support for QGraphicsItem. We initially had another subclass of QtAnimation that would animate QGraphicsItem but that ended not helping much because the default QGraphicsItem can’t do much (only position). If you feel like to you can still subclass QtAnimation to add support for your own types.

For animations the first-class citizen is now QtPropertyAnimation. It can handle variants and has support for easing curve, interpolation and key frames. We know that the main concern people usually have when it come to using intensively Qt’s property system is that it uses QVariant which is slow. We did quite some profiling and performance is also much improved in that direction since the last version of this framework. When you want to animate “something”, the only thing you need now is to add a property and then use a QtPropertyAnimation on it.

On the demo side we still have our little demos including the nice sub-attaq. API-wise the new stuff is hidden behind the scene and you’ll have to have a look at the code or implement your own little demos to see the changes.

Hmmm OK we know that’s not good enough!
So we know you’re a big fan of stick men so here’s a little video and you can see him do some actions. This demo is called stickman and is also provided with this solution (press D, C or J to change the current “action”).

Here you can enjoy it before he dies ;-).

To download the solution you can go here. Don’t forget to give us feedback. The new target for the framework is to be included into Qt 4.6.

Hi all, a short braindump from me here. Sometimes the best way to get things out of your head is to write things down. And there’s a cabin trip for Qt Software this weekend; I don’t want to be thinking about code (yeah right!).

Qt is designed to support both direct (framebuffer, software) rendering (fex Raster, our current default engine on Windows), and indirect rendering models such as X11, OpenGL, and perhaps other future engines such as OpenVG. Graphics View encapsulates structured graphics in Qt into a mid-level API that hides some of the painting details (while giving you full control to do detailed painting). It provides an object model / scene graph, and an abstraction over the rendering pipeline that lets us do many neat tricks to make it easier to run the same application efficiently on several different rendering architectures. Because Qt decides when and how your item is drawn, this gives Graphics View useful control:

• Qt calls QGraphicsView::paintEvent
• QGraphicsView::paintEvent calls QGraphicsView::draw{Background,Items,Foreground}
• each call goes to QGraphicsScene::draw{Background,Items,Foreground}
• QGraphicsScene::drawItems calls QGraphicsItem::paint

Speed. Software rendering can be very fast, and pixel perfect, although it doesn’t scale very well. For small devices, we’ve seen that software rendering can even outperform GL and do quite amazing things: fullscreen effects and blending, even blur. Still, the GL chipset can often do things faster. It’s just a matter of knowing what it can do, and how to make use of it. But it’s very rare that hardware acceleration gives you pixel perfection and 100% pixel-by-pixel control. The closest you get in other paint engines than Raster is either by rendering into an intermediate paint buffer (using Raster!) and passing that to the rendering system, or by using a shader/fragment program as is done in OpenGL 2.0 (which, on desktop systems with modern cards, produces very very good results!). With indirect rendering models there are several classic “problems” that lead to slow and jerky, sometimes ugly-looking graphics, if you make the assumption that it works just like software rendering. Rotating a pixmap on X11 requires a client-server network roundtrip (or unix domain socket). OpenGL has extensions that allow video playback, but the equivalent of a real-time software 2D/3D rendering engine pushing its pixels onto a GL context is absurd; it’s just not how GL works. The basic idea with indirect models is that you should try to store as much state as possible server-side (X11) or on the graphics card (OpenGL). Fonts glyphs, standard icons and transformable theme elements, push them over! Then per frame all you need to do is say where you want the elements drawn, and how.

Now QPainter has an imperative API that’s based on rendering vector and pixmap graphics to a device. If you want to support an indirect rendering model efficiently, you should render your contents into a buffer which can be passed on to the graphics system, and then referenced when you need it. In Graphics View, because the rendering abstraction is slightly higher, you can avoid having to do this by enabling what we call “Cache Modes”. Notice that cache modes are implemented on top of QPainter, and QGraphicsView is a regular widget, so all Graphics View does is use the cool stuff in Qt, and put it together in a way that’s hopefully useful.

item->setCacheMode(QGraphicsItem::ItemCoordinateCache);

Cache modes are for configuring two different types of offscreen buffers in order to accelerate item rendering:

• ItemCoordinateCache / “Item cache”
  • Rendering the item using an untransformed painter, into a pixmap that is “axis-aligned” with the item’s local coordinate system
  • The pixmap is truncated to the item’s local bounding rect
  • The resolution of the pixmap is configurable
  • The result is never pixel-perfect
  • Repainting the item happens if
    • You call update() on the item
    • The item’s geometry changes (prepareGeometryChange(), or updateGeometry()).
• Examples: The Qt 4.5 “Boxes” Demo (written by Kim Kalland), and Samuel Rødal’s WolfenQt, use ItemCoordinateCache to allow transformations without repaints.

• DeviceCoordinateCache / “Device cache”
• Rendering item using a transformed painter, into a pixmap that is “axis aligned” with the viewport
• The pixmap is truncated to the item’s _mapped_ bounding rect. (mapped to view)
• The resolution of the pixmap is fixed and unconfigurable
• The result is pixel-perfect (no visual difference from direct rendering)
• Repainting the item only happens if
  • You call update() on the item
  • The item’s geometry changes (prepareGeometryChange(), or updateGeometry()).
  • The item is rotated, scaled, sheared, or projected
• Example: Plasmoids in KDE use DeviceCoordinateCache to avoid repainting when moving applets around

ItemCoordinateCache has a visual impact because it requires you to decide in advance what resolution your off-screen pixmap should have. This is the only way we can avoid any repaints unless the item wants to be repainted. Here’s what the different cache modes end up presenting to the user:

NoCache / DeviceCoordinateCache	ItemCoordinateCache	Low-res ItemCoordinateCache

You can compare DeviceCoordinateCache to rendering exactly what you see in the viewport, at that exact resolution, but into a secondary buffer first. This ensures that the item is rendered in a pixel-perfect way. However, it also means the item must be rerendered when scaled, rotated, sheared, projected. If you transform the item in a way that ends up being a pixel-translation on the screen, the pixmap is just reused and redrawn at a new pos.

The purpose of these modes is to avoid having to repaint the item. In any indirect graphics system, repainting the item requires some sort of a roundtrip as image or vector data is transferred from one side of the graphics pipeline to the other. This is often expensive. QPainter translates into raw OpenGL calls or shader scripts when you draw onto a QGLWidget, and can (as the Pad Navigator Demo shows) produce OpenGL UIs that run fast (but on fast hardware!). However with limited hardware, poor OpenGL chips, when the graphics bus is slow as is common on embedded GL chipsets, the best approach may be to push textures to the “other side”, and “remote control them”.

For the “colliding mice” example, direct rendering is used (i.e., no cache). You get the best performance from this example on Windows, or when running Qt 4.5.0 on Linux with “-graphicssystem raster”. If you switch to OpenGL, it will still run fast, but not as fast as you’d expect for an OpenGL-powered application. So maybe a cache mode would help? Well for one, DeviceCoordinateCache is unsuitable for this demo, as the mice are continuously rotated (invalidating the off-screen buffer at every frame). ItemCoordinateCache is a good match. By setting ItemCoordinateCache on the mice, the mice don’t look as pixel-perfect as without it (especially using Raster), but graphics performance is very high - in fact rendering of the scene goes down to taking ~0% of my desktop system’s resources (the bottleneck of the example becomes the collision-detection). On embedded systems with no FPU, ItemCoordinateCache can also be faster btw, as the example is very floating-point and path-heavy, and painting rotated images might be faster than doing those floatops.

OT: I just want to mention at this point that some people have requested that cache modes become “implicit”, i.e., Qt should devide for you, and you shouldn’t need to toggle something as low-level as this. For a very high level API I would agree. But at the abstraction level Graphics View lives, QGV does not know whether you need pixel-perfection or not, and it does not know if you intent to rotate your items a lot. Only you, dear item author and user, know :-). And that’s why the API is there.

Now what’s happening on the research side with Cache Modes? We are currently researching subtree caching.

Graphics View’s cache modes work fine with simple items. But what about more complex items; items with children? Today, you need to explicitly set the right cache mode on each child. This isn’t an uncommon situation to be in. You stack items inside each other, like you would typically do when creating forms, layout stacks. If you want to do transformations on the whole thing, the most optimal solution is to have the entire item subtree collapsed into a single texture, which is then transformed. In contrast, painting several smaller items (sometimes there’s many of them! 50-100?) with a transformation can be very costly. Either it’s sluggish (no cache) or it exhausts your texture memory (individual caches).

The “Embedded Dialogs” demo shows how a dialog, which represents a potentially complex subtree, is collapsed into a single surface to ensure that there are no repaints as the dialogs are transformed when hovering in and out. This is a “happy accident” though ;-). The QWidget subtree is proxied into a single QGraphicsItem. But it did get me and several others thinking, why doesn’t QGV support this for any kind of item subtree?

On the left, the item is rendered using no cache (direct rendering). The middle image shows how each element is individually cached, which is the only approach you have today (Qt 4.2, 4.3, 4.5.0). On the right all items are cached into a single surface allowing “no repaints”, while conserving texture memory.

Collapsing a subtree into a single offscreen buffer is possible. I’ve spent two days this week researching it, wrote some code, and ended up with a prototype that’s so ugly I don’t want to share it _just yet_. But I’ve seen that it’s perfectly possible without messing up QGV’s internals. I dubbed two new cache modes:

• DeepItemCoordinateCache - caches the item and “all” children, no repaints for “any” child if the parent is transformed
• DeepDeviceCoordinateCache - save for DeviceCoordinateCache

During prototyping, I found a few issues that need to be solved, but it’s not a huge job to make this work.

• I currently have no idea how to handle ItemIgnoresTransformations
• Window children probably shouldn’t be collapsed into the same cache
• As children move, transform or update, the changes must be recorded in the caching parent’s offscreen buffer
• Combining existing cache modes with new deep cache modes should work fine (i.e., parent sets deep cache, child already have itemcoordinatecache)
  • But what if the child uses DeviceCoordinateCache?

How can deep caching be reused in an unexpected way?

• In the chip demo, when selecting and moving items around, we can temporarily reparent all selected items into a parent, enable deep device coordinate cache on the parent, and then remove the parent when the items stop moving. This means that even though you might be moving hundreds of items around, you’re actually only _really_ moving a little pixmap. Hah!

So many unanswered questions, but that’s the fun part with research. Since I have seen that it works and produces the result I want (no repaints! whole dialog lives in graphics memory), I’m certain the answers to the questions above will show up one at a time.

OK that was a long blog, but I felt like writing it all down.

What do you think? Is DeepItemCoordinateCache and DeepDeviceCoordinateCache useful?

I am just posting the link of Artur who work in INDT. They are working with us on animated layouts using Qt Kinetic.

Click for the full blog post

PS : Oops, i forgot to say that it works on Windows too.

Today we is a day that will be remembered for a long time in Qt history (I expect that we’ll remember it all the way until next week at least — that’s at least a thousand commits). I made today two 280,000-line changes to Qt, touching over 6500 files in each. At the end of the day, three Qt branches (4.6, 4.5 and 4.5.0) now contain the LGPL license header in all Qt’s .cpp and .h files, plus an assorted set of scripts. Third-party code is obviously excluded from this change. That means the GPL era of Qt comes to its end — and LGPL starts.

Today, I stopped the cron job that creates and publishes the Qt snapshots. Mostly because the LGPL and other changes are very likely to break stuff. And that we don’t want the snapshots published under the LGPL until we actually release 4.5.0 next month. What’s more, I don’t know if snapshots will ever come back: maybe we will go directly to the open repository. That’s the end of the snapshot era.

Today, Alexis also made changes to the Qt repository in Git, removing the never-released files and adapting the the license files. He also refactored the license part of the configure script and the Windows configure.exe (it’s a good thing that I turned snapshots off, because he went to ski shortly afterwards in a classical example of “submit-and-run” ). That’s one of the last steps required for the open repository, though there are a few minor things to go.

This week, the temperature in Oslo reached 0°C again. That means the snow is starting to melt and the streets are very dirty now. The mountains of snow that we have collected over the past few weeks will gradually disappear. That’s the end of Winter, but I hear it will come back (I don’t put too much faith in those rumours).

This month, I’m also stepping down as Release Manager for Qt. I had pre-announced this at Developer Days last year, but it’s effective now: after 18 months and releasing Qt 4.3.3, 4.3.4, 4.3.5, 4.4.0-tp1, 4.4.0-beta1, 4.4.0-rc1, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.5.0-tp1, 4.5.0-beta1, 4.5.0-rc1 (and two mac-cocoa alphas), it’s time I pass the torch to the next poor sob brave soul to take on the job. So this is also the end of my era as Release Manager. (No, I’m not leaving Qt Software, I’m just moving on to other responsibilites)

It’s interesting to note that the change in RM matches the change in environment. It’s tradition that each new RM gets to rewrite the release scripts from scratch. The RM before me had all of it working for our setup with Perforce. I rewrote it to use Git. After me, you can’t call them release scripts anymore, because I rewrote them in C++, using memory-mapped files and QtConcurrent. Now my successor will have the chance of rewriting it to match the open repository. It looks like packaging will be a lot simpler, since there will be no file editing or removal.

This is not a sad time. At least, I haven’t seen anyone crying their eyes out in the office. So I must conclude that this is a happy time: the end of an era marks the beginning of a new one. We can only hope that the new era will be even better than the current. We’re certainly going to make our best effort.

Disclaimer: this blog could be part of a conspiracy against Qt on Windows.

Qt already provides a set of standard icons. The nice thing about these icons is that they adapt to the current desktop environment. However the current selection of available icons is rather limited, at least compared to what KDE apps have at their disposal through the freedesktop icon specification. Since most of these icons only are available on the X11 platform, we still haven’t decided how to make them available to pure Qt applications such as Designer and Creator. While we are thinking about that, I thought I might as well wrap up the essential code and provide it as a simple convenience class, QtIconLoader, that you can use in your own project. You can find the source code here.

The class currently only provides one static function:

QIcon QtIconLoader::icon(const QString &iconName, const QIcon &fallback = QIcon()).

Usage should be fairly obvious:
new QAction(QtIconLoader::icon(”document-new”), tr(”&New”), this);

The fallback is of course for platform compatibility so you can provide your own masterpiece as a fallback for other platforms, which is probably the icon you are already using.

And since no blog post is complete without some eye candy, I modified our well know textedit example to QtIconLoader:

Here is how it looks running on KDE 4.2:

And since we also pick up GNOME settings, this is how it looks when running GNOME:

I’m sure there are bugs. For some reason freedesktop standardized on everything except a convenient way to detect which theme to use, so we need to do some trickery to get to the KDE and GNOME settings. Feel free to report issues and suggestions here.

Hi fellow hackers,

I have found a bug in my brain, it does not emit the readyRead signal properly which means all the public information that was meant to be published at appropriate intervals is not processed. Here follows a manual flush of what I’ve been doing since last time. Talking about everything is too much, so I’ll give you a brief overview.

Last year was pretty much spent on optimizing/re-factoring code related to the Qt Falcon project where the goal was to make Qt 4.5 fly. I mainly focused on painting performance for widgets, i.e. the backing store / window surface infrastructure. After spending a fair amount of time profiling different painting scenarios, I found out the backing store infrastructure was too poor to improve. It simply had to be re-factored in order to make it fly. I finally had an excuse to wear my latex laboratory gloves and white coat in public (I usually only wear this kind of equipment behind closed doors when lobotomizing colleagues). With all the equipment in place–including liters of coffee–the time had come. I was about to replace our platform dependent beast with something new and shiny–preferably cross-platform. After some tough work and patching throughout 2008 I ended up with something useful. Let me remind you that there are no problems, only solutions. I basically removed a lot of QRegion operations and made the update mechanism a whole lot smarter, in addition to many cut-offs for opaque widgets. I will leave out the details and let these numbers speak for themselves:

Download the sources from here.

With a new and optimized backing store, we were one step closer the goal. While I was working on the new backing store, the other falcon guys were working on a brand new graphics system whose goal was to make it possible to switch the rendering back-end. In order to achieve that, all the painting had to go through our backing store. We had never used the backing store on the Mac before, so my next action point was to put the pieces together and make it happen. Voila, “-graphicssystem raster” on the Mac was no longer just a wet dream. And yes, it was a little bit harder than it sounds.

During all this hacking I also decided to go to DevDays in Munich and Redwood, which implied that I had to prepare two presentations; “Advanced Visualization, Widgets On Graphics View” and “Alien Widgets & Widget Rendering”. I spent quite some time making these presentations the best since sliced bread, and I really hope they were entertaining and interesting. Dev Days 2008 was such a great event and I really enjoyed my stay.

Few days later, back in business here in Oslo with turbo charged batteries, I felt a bit disappointed that I couldn’t show off a graphics view embedded inside graphics view embedded inside another graphics view etc. I knew it wasn’t going to work, so I didn’t even try. However, I made an example having exactly two redirections and that seemed to be more than enough for the hackers in the room, based on the applause it received. This limitation was made on purpose to ease and simplify the shared painter and QWidget::render. However, I was not satisfied with it and thought it would be cool to remove it without adding overhead, so I sat down and did some brain work. And as usual there was a solution to my problem. The shared painter, and hence QWidget::render, now supports an arbitrary number of redirections. Have a look at WolfenQt to see it in action, there’s no limitation of how many times you can “walk into” another graphics view. HTML-5 video in QWebView is another example. Pretty cool.

With that out of my way, I found time to look into a very annoying issue that has followed us since Qt 4.0: “Qt::WA_StaticContents does not work”. Well, it worked for Qt::WA_PaintOnScreen top-levels, but not in general which is really bad since the attribute can have an incredible impact on the performance on resize. It basically means “Dear Qt, do not repaint my entire rect on resize and only repaint newly exposed areas instead”. Just think of it next time you expose yourself for the sun; does it make sense to wear off all the clothes and put on sun lotion on the entire body just because parts of it is exposed? I hope not. I therefore decided to implement the Qt::WA_StaticContents attribute for all widgets in Qt 4.5.0 and here’s the result:

Download the sources from here (run with “QT_FLUSH_PAINT=10″ in debug mode to flush repainted areas with yellow).

I have done several other things too, like fixing lots of bugs, reviewed patches, fixed auto tests, helped out with recruitment, promoted Qt Software at various events and so on. All in all very exciting stuff, and I look forward to new challenges and exciting stuff in the months to come.

OK, that’s it for now. I promise to blog more often in the future, or even write a QQ article (mostly to give back something to Kavindra who has provided me with an unknown number of delicious muffins).

Have a nice weekend and happy hacking!

If you want to learn Qt, and French is your favourite language, we have good news for you: the main Qt tutorial for Qt 4.5 is now available with French explanation. Pierre and I have translated the tutorial with the help of Kavindra and David and we have successfully got everything to work (encoding problems are more easily solved in Qt than on the Web…)

If French is your mother tongue, you will be happy to learn that there is a lot of resources available in the French Qt community. One very active community is http://qt.developpez.com/, who have translated the complete Qt tutorial. They have a forum, many original articles and new translations coming soon. Also, there is another community, QtFr, with tons of articles and an active forum.

Si vous voulez apprendre Qt et que le français est votre langue préférée, nous avons une bonne nouvelle pour vous: le tutoriel de Qt 4.5 est maintenant disponible avec les explications en français. Pierre et moi avons traduit le tutorial avec l’aide de Kavindra et de David et nous avons réussi à tout faire fonctionner (les problèmes d’encodage sont plus facile à résoudre dans Qt que sur le web…).

Si le français est votre langue maternelle, vous serez heureux d’apprendre qu’il y a énormément d’aide disponible dans la communauté francophone. Une communauté très active est sur http://qt.developpez.com/, ils ont entièrement traduit le tutoriel Qt. Ils ont aussi un forum, tout plein d’articles originaux et de nouvelles traductions sont attendues prochainement. Sans oublier la communauté QtFr qui propose des tonnes d’articles et un forum.

It has some time gone since I implemented the plasma widget to show the in-time departure information for local public traffic in Dresden, so I thought it is the right time to do something similar again. My current location is Oslo and it is really cold here (-14 this night), so you really don’t want to wait 10 minutes at the bus station for the next bus. Fortunately the local transport services trafikanten.no provides a WAP service that allows you to retrieve the departure information of busses, trams and subways as WML pages. WML is a XML based markup language, so one would immediately start the favorite editor and hack together a bunch of code that uses QNetworkAccessManager to load the document from the internet and QDomDocument or QXmlStreamReader to parse the documents for the relevant information. However this approach needs a lot of glue code, and writing that wasts a lot of valuable time…

So today I want present a more efficient and smart way of doing that: QXmlQuery
This class is part of Qt since 4.4 and provides an implementation for XPath and XQuery (in 4.5 also XSLT), both are query languages to extract parts of XML documents with a rich set of filter rules. Extracting the time information from our WAP services needs only 5 - 10 lines of code + the code for representing everything on the screen:

I could now list the source code of this application here and explain how it works, however that would be duplicated work because that is already done here

So the application is only based on Qt, as it’s part of the example applications for Qt 4.5, but maybe there is some brave soul that converts it into a real plamsa widget? You can currently choose the station you want to departure information for and even filter for the bus/tram/subway number you are interested in. More features are not planned, to keep the example small and if you live outside Oslo, the departure times won’t help you anyway but it is an excellent example that shows, how to use QXmlQuery for accessing web services easily.

Sebastian Kügler blogged yesterday about why distributions shouldn’t jump on upgrading to Qt 4.5 while shipping KDE 4.2. This caused quite a stir in the community as well as inside Qt Software. Sebas then replied to Cyrille’s blog explaining a bit more (if the link doesn’t work, scroll down; blogspot comment links don’t do anything for me).

Sebas is right: Plasma developers did not test KDE 4.2.0 with Qt 4.5. So there may be issues that they have not seen or corrected. That’s entirely true and no one can blame the Plasma developers. After all, resources are limited and prioritising the work was necessary. Therefore, distributions should be careful when upgrading Qt, because they may introduce problems. But, then again, isn’t that the job of distributions? To make sure their package set works without issues? And in case patches are needed, they can backport fixes from upcoming releases or introduce a temporary hack.

However, Sebas is right only up to a point. We at Qt Software have done testing of Plasma with Qt 4.5. In fact, we know it works better with 4.5 than with 4.4.3, though some of the qt-copy patches help somewhat. Has anyone noticed that the system tray finally works in 4.5? But, more importantly, other parts of KDE (other than Plasma) benefit greatly from Qt 4.5.

Just to give you an example: I still build my KDE trunk with Qt 4.4, then run with 4.5 on my main development workstation, but with the standard 4.4 (pristine, unpatched) in my laptop. After logging in to KDE, I usually get Kontact crashing within 5 minutes of using: when I click on a folder, it crashes with a dangling pointer dereferencing. Then I remember I have to restart it with QT_NO_SHARED_PAINTER=1. But this crash never happens on my workstation: standard 4.5, pristine, unpatched.

What’s more:

• We did lots of testing and fixing of KDE 4.2 for Qt 4.5, but not with Qt 4.4
• We did a lot of fixing and stabilisation in 4.5 itself and most of these changes did not make into 4.4
• Performance improvements in 4.5 are noticeable, especially in the painting code and itemviews

I can hear the arguments saying that those fixes should have bene done in the 4.4 line and that we should have prioritised that over the feature release. I know those arguments because the discussion happens in Qt Software too: it’s only natural to have it. But the same way that Plasma developers were faced with a finite amount of resources, so were we: we had to prioritise work. Qt 4.5 is the future and we needed to stabilise it, so we did focus most of work there. (We did not forget 4.4, you can find several fixes in the Qt 4.4.4 snapshots)

And I don’t have to say that we can’t fix further issues unless they are reported to us. If people don’t use 4.5, those issues will not be found (read: our QA people can’t find every single issue). With the 4.4 release, we had a very good feedback from the KDE community: KDE 4.1 started using 4.4 very early, I think even before the beta (Feb 2008). That means we had a lot to work with in order to stabilise Qt 4.4. By the time of the 4.4 release candidate, we had had two months of continuous feedback and stabilisation work done. And we have one more month left, more or less, by which time KDE 4.2.1 (with its own set of fixes) should be out.

And my personal, subjective experience comparing now (4.5 RC) to 10 months ago (4.4RC), things are a lot better and more stable.

I am actually in Porto (Portugal) for the Tokamak version 2.0. Tokamak is a developer meeting for the Plasma KDE project. I arrived Friday and the first day was talks, people explaining on what they are working on for KDE 4.3. There will have some awesome features that make Plasma the best desktop ever. From my side i gave a talk about Qt Kinetic to introduce them the project. The first feedback i had was that this project is warmly welcome, and miss to plasma developers (and i guess to others). I introduced the Qt State machine framework, the Qt Animation API and talked about improvements in QGraphicsView. I had nice feedback from people and they were pretty happy about the API. I wrote all their remarks on a paper to work on them with other trolls. I have already implemented some of them inside my local copy of Qt Kinetic :D. The team is now waiting a Qt Solution in order to “kineticize” Plasma.

I have cooked a small demo showing Plasma running Qt Kinetic :

Ogg Video

You can see an animation on the opacity during switching pictures and an another to display one day meta data behind the picture.
Here is the code for the opacity animation :
QPropertyAnimation *opacityAnimation = new QPropertyAnimation(this,"opacity");
opacityAnimation->setEndValue(0.);
opacityAnimation->setDuration(1000);
opacityAnimation->start();

By the way Qt 4.5 RC is now in qt-copy and KDE trunk use it. After talking with all people here the switch is apparently nice. I have asked to all people to give a mark from 1 to 10 (ten is best) based to their user/developer experience. The average is 8 which is nice. According to Aaron Seigo the switch in Plasma was “pretty smooth” and Leo Franchi from Amarok said “it seems faster with raster graphic system”. Marco Martin added “QGraphicsLayouts start to work”. There are still some small problems with SVGs rendering in Plasma but i will sit down with Marco to fix them. It is encouraging for the final release and we will have now KDE folks reporting bugs they still have with 4.5 to make this release the best as we can.