Over on Planet Classpath the people blog about the ongoing
efforts and success with their Qt based AWT peers.

Nice to see that the high quality of Qt's code on all its platforms get more widespread acknowledgement outside the KDE area.

Well, not all of them.
Those that create tons of structs for datatypes and even more functions to work with them.
I hate them because they almost look like sane OOP APIs but are awfully to use compared to
what real OOP languages would offer

Consider this example:

void foo()
{
CFStringRef cfstring =
CFStringCreateWithCString(NULL, "http://wwwkde.org/", kCFStringEncodingUTF8);

CFURLRef cfurl = CFURLCreateWithString(NULL, cfstring, NULL);

// use the URL

I have blogged about QDS, my Qt desktop integration library, almost exactly a year ago.

Unfortunately I didn't have much time back then due to serving at the Red Cross
(instead of serving in the military; Zivildienst for the German speakers).

However, as the QDS part of my webspace got quite some hits after mentioning QDS on the Dot,
I decided to have a look at it again.

While preparing for my talk on KDE commandline scripting I discovered a couple of new commandline clients.

So afterwards I continued to look for possibilities of accessing KDE from the commandline.

Last week we had our local Linux event of the year called Grazer LinuxTage which is part of an Austrian wide series of events called Linuxwochen.

KDE, the integrative desktop environment.

I can't remember who came up with this but it is so true.
By providing interfaces (kdelibs/interfaces) KDE enables choice without negatively affecting KDE interoperability.

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

Collection of ideas on how to encourage more developers to develop with KDE.

I have been doing developer support on mailinglists, newsgroups and web forums for about three years now.
Support means helping developers solving development problems, especially for developers who are new
to Linux, Qt or KDE.

Helping developers new to KDE is quite difficult, because a lot of our advanced stuff is not so easy to
understand if you haven't already used it.

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.