Oh, I almost forgot. I sat down yesterday night and played a little bit with Cairo. It does have quite a nice API. A full example is at http://vortex.bd.psu.edu/~mkr137/qcairo.tar.bz2 . It's a pure Qt application. You don't need KDE to compile it. It shows how to use Cairo API natively from a QWidget:: paintEvent (you may need to adjust the library paths in the qcairo.pro file).

Just came across this article via msdn, C++: The Most Powerful Language for .NET Framework Programming. Microsoft seems especially pleased with their new version of Managed C++. They've done a complete revamp of their previous .NET support for C++ and submitted it to ECMA and ISO as a standard. This brings C++ inline with C# as far as first class support for the Common Language Runtime. I really like what they've done to improve the C++ experience for .NET, but still think it will be incredibly hard to adapt the Qt/KDE libraries to fit into this framework. Consider this annoyance, the new proposed standard mandates PascalCase be used for the core API. For a technical challenge you'd have to consider how to integrate MOC and the new C++.NET properties. Read on.

Ok, so Qt 4's listview / table / iconview / listbox replacement is called "Interview" collectively. I started playing around with it last weekend and well, there's some good and some bad. The good is that at least from an initial take on things the performance seems much better. This could just be the double buffering tricking me and making it look smooth since I haven't actually done any really intensive tests on it, but it certainly feels more responsive.

Caution, rant ahead!

I started working on an extension library for Qt applications which should enable them to use service or features offered by desktop APIs without creating link time dependencies on the respective desktop libs. http://www.sbox.tugraz.at/home/v/voyager/qds/index.html

Last night I downloaded the Qt 4 preview and had a play with it, so far I'm very happy. The new painter code seems great and the GL painting demo suggests a lot fun ideas.

Qt 4 solves one of my big annoyances with the Qt API by introducing a common base class for items in list views, tree views etc. This change will make it much easier to let the user choose how information is displayed as we can have dialogs that switch between iconviews, listviews and trees without having to write the same code three times. In fact, when combined with the new model-view facilities (which I have yet to examine) this may be something that can be encapsulated in a single widget.

Letting Qt applications user aRts as their sound backend.

Short introduction: currently most of my KDE related time is used to help newbie Qt and KDE developers. When one of the user of www.mrunix.de, a German Unix/Linux developer board, had a problem with Qt sound (didn't have have NAS installed), I decided to try implementing an aRts backend for Qt.

Ugh, another bugfix rejected. This one affects at least KAlarm, JuK, KGPG, KGet and Kopete. Bug was acknowledged; patch acknowledged; won't fix before 3.3 (probably more than a year and no help for KDE 3.2).

http://www.derkarl.org/cvscommits.phtml?id=46437
Mothers hide your daughters Qt 3.2 is now in CVS. So does this mean its time to move up?