Ever since the first technology preview of Qt4, and probably even before, KDE 4 has been the subject of wild speculation. The KDE Project actually discussed starting the KDE 4 branch as far back as August 2004 in a birds of a feather session. Two major releases later and the developers are finally buried deep in their libraries, overhauling and rethinking the basics of their desktop environment. By the time KDE 4.0 is released, which could be late this year or early 2007, developers will have a lot of new toys to play with.

To give you an idea of what KDE 4.0 will be like it's worth looking back at KDE 2.0, which could almost have been described as a technology preview rather than a complete desktop environment. Basic building blocks for KDE first surfaced in that release, such as the KIOSlaves that enable all KDE applications to handle all kinds of data transparently, from networked machines accessed by ssh to man pages and Beagle searches. In KDE 3.0 those technologies finally matured, and through the 3.x series we have seen the developers realize their promise, creating the desktop that so many know and love today.

KDE 4.0 is going to be a bit like KDE 2.0 - although far more useful and mature - in that it will first expose a lot of infrastructure even if few of the applications manage to exploit their potential. According to Aaron Seigo, the core developer of Plasma:

Users are only likely to see applications using the infrastructure in interesting ways by KDE 4.1, and then through the rest of the 4.x series it will mature in the same way as 3.x. Hopefully it will happen with greater speed than KDE 2 as we aren't starting completely from scratch everywhere and we have a bigger development team. I'd expect early adopters and "tourists" to jump into kde 4.0. but not school or enterprise deployments.

Of course for developers this doesn't matter, the hype is all about the technology, so even if Seigo is right and KDE 4.0 is a "first draft of a post-technical preview type of release" there will be plenty to play with. Don't say "vapourware" to a KDE developer!

Phonon, Solid, Plasma, Akonodi: these are the buzzwords that give substance to the hype. Each mini-project is targeted at making developers' lives easier, which is a big part of the KDE development philosophy: give developers great tools and they'll make great applications.

Phonon addresses the complexity of audio and video functionality in applications, whether they're simple games with silly beeps, instant messengers that need audio and video devices, or complex mixing studios. The API should allow developers to get on with the application and have a reliable, desktop-integrated multimedia framework do the boring work. At the moment, for example, Kaffeine can embed videos in Konqueror but it is prone to crashes because it has to make kernel-level calls on its own. With Phonon, developers can do away with such hacks and concentrate on one API if they want enhanced functionality.

The other design decision was to allow developers and users to use different multimedia frameworks underneath Phonon - such as GStreamer, NMM, MAS and Xine - rather than simply integrating one into the KDE libraries. This decision, popular in Amarok, should promote more innovation amongst developers and choice for users, though it will also undoubtedly be more work than just adopting, say, GStreamer, as the GNOME developers have done.

Solid takes up the challenge set by Robert Love's Project Utopia, and will try to make interaction with hot-pluggable devices and networks more, well, solid. KDE already uses DBUS and HAL to provide basic functionality that is almost equivalent to that found in GNOME, Microsoft Windows and Apple MacOSX. But integration has been hard work, and in KDE 3.5 it can only shine through KIOSlaves and other "old" technology. The main design goal of Solid is to give developers a single, consistent API so that the desktop can become more flexible and integrated, much like Love's goals with Project Utopia. It should be easy to make your application fully aware of changes in network and hardware availability. The second design goal is to avoid locking KDE into platform-specific technologies like HAL (which currently only works with Linux).

Plasma will unite and rethink various components in the desktop, including kicker and its various applets, SuperKaramba widgets, the K Menu application launcher, the Run Command dialogue and the desktop space itself. Eye-candy addicts will enjoy the more beautiful design that it brings, but developers are more likely to appreciate the elegant API. Based around a few basic elements, Plasma should help the desktop become a truly functional space rather than a dumping ground for downloads and systray applets. The lofty ambition of Plasma is to completely change the way we interact with the desktop, becoming "workflow sensitive". Project-based collections, network aware widgets for collaboration, interfaces that you can zoom in on to examine details and zoom out of to gain overview and free-form layout of add-ons are all being experimented with. But of course by KDE 4.0 it's likely to change developers' mindsets more than the actual implementation of the desktop.

There are many other ideas floating around, such as Akonadi, a storage layer for PIM (personal information management) applications. But, like Akonadi, many of these ideas may not appear until KDE 4.1. By October we should see a technology preview, which will give developers their first chance to get hands-on experience with which to judge the hype. In the meantime there's always SVN and KDE 2.0 to give you a sense of the excitement.