By Daniel Molkentin
Right from the start of development, the KDE project raised expectations - the developers' blogs boasted that the desktop would be more attractive and work differently and the new release would also be much faster than its predecessor. Just a few months before the release, and shortly after the first beta version became available, we decided to find out how the KDE project is faring.
When you launch the KDE 4 beta for the first time, you immediately notice the changes to the GUI. Figure 1 shows the Oxygen icons in the first alpha version and the new Dolphin file manager. The new icons are a departure from the comic-book style of the Crystal icons in the KDE 3 series, and they are easier to interpret. Extremely simple icons in the task bar are a stark contrast to the other, more structured icons. Additionally, the icon set follows the Freedesktop.org  icon specifications, just like the Gnome project's Tango icons.
The arts team is still working on a new style for widgets to replace the previous "Plastik" standard. Because various Oxygen-style elements are not finished, you will not find them in the first beta.
Another fundamental change demotes the legacy desktop to the history books. Plasma now has mastery over the screen background, and applets - now known as Plasmoids - reside on it (Figure 2). The design is similar to that of SuperKaramba, which should be no surprise because several Superkaramba developers are members of the Plasma team.
The KDE window manager KWin is regarded as one of the pillars of KDE. Its developers taught KWin good manners in its daily interactions with many applications years ago. In the meantime, OpenGL-based window managers such as Compiz Fusion have seen major successes on the window and desktop front with the use of compositing to liven up the desktop with various effects.
Compiz is not a suitable replacement for KWin because the unstable API for Compiz plugins does not comply with KDE library criteria. Analysis of the code revealed that it would be more complex to port the complete KWin functionality to Compiz than to add compositing to KWin. The fact that Compiz only supports modern graphics adapters and uses proprietary drivers to do so (with the exception of Intel graphics chips) dealt the final blow to Compiz's aspirations.
KWin, on the other hand, has three modes. In OpenGL mode, KWin leverages the graphics card's 3D abilities, just like Compiz. If no 3D drivers are available, KWin switches to composite mode, where compositing in 2D is implemented by means of an X extension developed for the purpose. And if all else fails, you can still use KWin as under KDE 3. In other words, KWin now supports functions such as shadows, transparency, and animated overviews of the virtual desktops on any recent machine. The only drawback is that KWin can't match Compiz for performance yet.
One of the major strengths of KDE since version 2.0 has been its inter-process communication, which is handled by KDE's own DCOP protocol and gives applications the ability to talk to each other. DCOP is also a useful command-line tool that gives users the ability to script program control.
Almost any KDE application supports DCOP services. However, the protocol is based on Qt and the ICE library, which is one of the X Server libraries. The DCOP protocol is fairly inflexible when it comes to use outside of KDE, and it does not support interaction with non-KDE applications.
The solution is the D-Bus protocol, whose creators come from the Gnome and kernel camps, besides the KDE camp. This hardware abstraction layer (HAL) was the first program for the Linux kernel that "talked" to the D-Bus. Other programs, such as the network manager for dynamic network connection management, followed.
This works because D-Bus also has a system mode in which it supports restricted interaction with system instances, such as HAL and network manager, from inside a user session. Figure 3 illustrates how this works.
Developers will be migrating the DCOP interfaces to D-Bus for KDE 4, although this will be transparent to users. On the other hand, if you use scripts that rely on DCOP calls, you will need to convert to D-Bus calls, although the differences may be minimal (Figure 4). See the KDE TechBase  for details.
It has been hard for applications to interact with hardware in the past. Application developers have been expected to possess low-level knowledge to query even the simplest of details, such as the battery charge state. KDE 4 applications can access the "Solid" hardware information layer, which provides a hardware-querying interface. On Linux, Solid communicates via the D-Bus with HAL and relies on the network manager for network communications. The system service handles network management in most Linux distributions.
Platforms that do not use HAL or network manager can use plugins to provide their own Solid back-end to supply hardware and network information to KDE applications.
The KDE project has introduced a new layer, Phonon, for multimedia hardware. Phonon's speciality is the bane of many Linux users' lives - sound and video output. KDE 3 previously relied on the Arts multimedia sound server, which mainly mixed the audio streams provided by various programs.
From a technical point of view, Arts would have been able to output sound over a network, but nobody really leveraged this ability. On the downside, Arts suffered from issues such as noticeable delays in sound output. Plus, the project lost its maintainer and had to shop around for a replacement.
Matthias Kretz, one of the leading KDE multimedia developers, decided to launch Phonon to fill the void. KDE application developers no longer need to worry about the technical complexities of their program's audio and video output; distributors can simply supply one or multiple Phonon back-ends, and applications can rely on Gstreamer, Xine, or NMM to play music and videos. Of course, there is nothing to stop you from programming your own back-end.
Until a few years ago, find and locate were the only file-searching tools for Unix. Today, various desktop search engines create indexes for content on disk. On the Linux desktop, Novell's Beagle is the generally accepted standard.
This said, Beagle is slow, partly because it relies on external programs for indexing special files. The new KDE desktop search tool, Strigi, uses its own analysis tools wherever possible and speeds up the process by doing so.
Another bonus is that Strigi possesses special technology to help it find data in arbitrarily nested containers, such as in a tree of Zip containers. Additionally, the tool relies on its own analysis modules for any file type, thus speeding up the indexing process.
Strigi typically beats its competitors in a Sun benchmark, even in trivial tests . Currently only a minimalist front-end, Strigiclient is available for Strigi, but the developers are working on improving integration.
The semantic desktop, represented by Nepomuk (see the "Nepomuk Project" box) is making slow progress. The Dolphin file manager has rating and tagging functions for individual files (Figure 5).
Thanks to automated tagging (for example, based on existing metadata), users will be able to locate files more precisely than ever before.
In the future, besides giving your digital camera's tagging function direct access to Nepomuk, the technology will be capable of implementing Amarok's tagging system. The "tag pool" would then make the data available to any program that uses Nepomuk.
Nepomuk (Networked Environment for Personal Ontology-based Management of Unified Knowledge) is a project that aims to extend "the desktop to a collaborative environment." Researchers have been working on the project since 2006, and the EU has contributed 11.5 million Euros in funding. Project partners include IBM, HP, SAP, the German Research Center for Artificial Intelligence in Karlsruhe, and other institutions from EU countries and Switzerland. The distributor and Nepomuk partner, Man-driva, is handling KDE integration and has assigned K3b developer Sebastian Trüg to the task.
Dolphin is the developers' response to user requests for a simple file-management tool (see Figure 1). The application has a simple interface with "Places" (your preferred folders) on the left in a style that reflects the file dialog. Dolphin uses the right-hand panel to display detailed information on the current file selection. The central area is filled by one of a choice of three folder views; in addition to the icon and list views, there is also a Finder-style column view that opens up a new column for each level of the directory tree.
Navigation in Dolphin uses an address box with a bread-crumb trail. If you click a free area or press CTRL+L, Dolphin reverts to the standard input box. All of this gives Dolphin a tidier look and feel than Konqueror.
Konqueror's developers are now focusing on the tool's Web-browsing abilities. Although there was a discussion recently concerning Apple's Webkit (a KHTML fork), Apple now cooperates with KDE and companies such as Nokia and Adobe on the Webkit through an open repository, and Trolltech is looking to incorporate the Webkit in Qt 4.4. The same technology is scheduled for integration with Konqueror as KPart.
Users of "Web 2.0" sites, which Webkit handles better than KHTML, will have to wait for this technology; however, KHTML will still be the standard in KDE 4.0.
KDE 4 will support Windows and Mac OS, but the project lacks developers to port the code, and KDE 4.0 for these platforms is only available in what KDE calls a "preview version." You can run a simple installation routine to install KDE on both platforms.
The use of Qt guarantees a fairly native appearance, with just the icons smacking of KDE. The KDE developers have no ambitions to migrate more than a couple of desktop applications. The goal is to facilitate the migration process for companies who are interested in changing platforms.
Running a program on KDE 3 typically means using a single processor core, but thanks to improved thread support in Qt 4 and the Threadweaver library by Mirko Böhm, this is now set to change. Threadweaver bundles queued tasks to create jobs that can be distributed over multiple cores. Threadweaver then forwards the results of its activities to the programs in question.
In other words, developers no longer need to mess around with threads dir-ectly in order to leverage the potential of multiple-processor systems.
The KDE developers have also addressed Personal Information Management (PIM). Frustrated by bottlenecks in the current design, developers dreamed up a service that would act as an offline memory for PIM data, called Akonadi.
The design is reminiscent of the Evolution Data Server, but Akonadi also handles email, using D-Bus and an IMAP clone for communications. Akonadi works independently of the front-end, and the KDE developers hope that other PIM projects will be equally enthusiastic about Akonadi.
Groupware vendors could benefit from the architecture - a single Akonadi connector could serve a whole Groupware product. Work has started on Strigi integration to give users the ability to search for tasks, mail, to-dos, and addresses.
Because the developers consistently separate the user-specific service and the GUI front-end, it would be easy to process PIM data for use by Plasma applets or custom applications.
A KDE library for easy access to Akonadi already exists. Despite this, the Akonadi project will probably break through until KDE 4.1 is released, as the developers are currently busy porting the existing technology.
In a second step, which is likely to follow the KDE 4.0 release, they will then convert programs for use with Akonadi or replace them with new solutions.
Whenever developers embellish the Linux desktop, people are quick to accuse them of wanting to program a second Windows or Mac OS. In fact, Plasma is based on the SuperKaramba concept, which was around long before OS X and Windows Vista unveiled their widgets and gadgets.
Technologies like Nepomuk and Strigi have the potential to take the KDE desktop ahead in many areas, and KDE 4's graphical style is far superior to that of its predecessors, although there is still room for improvement in various places. The step toward D-Bus and technologies like Akonadi shows that the KDE developers are willing to cooperate with other projects, without KDE having to sacrifice its own identity.
At the same time, Akonadi is an example of one of the many technologies that will not make the freeze for KDE 4.0 - the desktop is holding back a few innovations for subsequent releases.
 The Freedesktop project: http://www.freedesktop.org/wiki/
 KDE TechBase: http://techbase.kde.org
 Sun's Strigi test: http://mail.gnome.org/archives/tracker-list/2007-January/pdfLkb0uuBAEw.pdf