KDE 4 promises radical changes to the free desktop

57

Author: Tom Chance

As the dust settles from aKademy 2005, the annual KDE conference, it’s a good time to take a look at what the KDE developers are working on. Though KDE 3.5 isn’t even out yet, developers are already working on KDE 4. Plenty of work has already gone into porting existing code to Qt4, the GUI toolkit upon which KDE is based, and KDE developers are working on projects that could radically change how the world’s most popular free desktop looks and works.

KDE 3.5 is due out in late October. The 3.5 release will give KDE users and developers a mature, stable, and integrated desktop platform with a wide range of applications.

Its developers see KDE 4 as a chance to experiment and introduce new concepts and applications that do more than build on the strength of KDE’s existing architecture. Just as KDE 3 brought major transformations in that architecture, developers are looking to KDE 4 to transform the desktop experience and enable a surge in third-party application development. With a KDE 4 release not likely to happen for at least another year, the developers have plenty of time to experiment.

A desktop with Appeal

Appeal is the most ambitious new initiative, and is more of a manifesto for change than a software project. Since the inception of the KDE project in 1996, developers have decided the direction of the KDE project. Usability experts and artists have taken on an increasingly important role in KDE, but have largely been relegated to cleaning up mostly completed work. Appeal is designed to change that. The Appeal project is a mechanism for bringing artists, usability experts, programmers, and enthusiasts together in the earliest stages of development by holding in-person meetings and maintaining ongoing communication over mailing lists, wikis, and Web-based forums.

Organizing your files – beyond hierarchies

One prominent effort in Appeal is Tenor, a “contextual linkage engine.” Tenor will gather contextual data — such as the metadata stored in MP3s, the contents of text files, and relationships between a file and the application that created it — and present it to applications via another KDE framework. This will allow applications to provide more useful ways of searching files for users. For example, using Tenor an application could bring up a list of “all the images I downloaded from the Web in the past week.”

The most obvious application of Tenor would be desktop search, giving KDE an analog to GNOME’s brilliant search tool Beagle. But the Tenor project’s chief architect, Scott Wheeler, wants to go further, asking, “how can we make it easier to work with the data we accumulate on the desktop?” So rather than just making it easier for users to search for documents, Tenor will provide application developers with data that can transform their interfaces. For example, the KDE Control Center, which currently organizes the configuration modules into a confusing hierarchy, may provide a search interface with results that show related items and learn from usage patterns.

The way Tenor is being developed makes it hard to predict how it will appear to users when KDE 4 comes out. Wheeler has no plans to make any applications that use it, opting instead to provide other developers with a framework that they can use as they see fit. Once the developers come to grips with Tenor, it is likely we will see innovation across the desktop, as searchable, navigable webs of information replace traditional hierarchical structures.

Making the desktop more functional and beautiful

For users looking for more tangible changes in KDE 4, Plasma is a project to design and implement an entirely new desktop shell, combining the desktop (including wallpaper and icons), the panel and its applets, and desktop applets like SuperKaramba into a coherent and innovative vision.

Four basic concepts in Plasma replace the existing mix of components: the desktop, applets, extenders, and panels. Applets will help you manage your work and organise your desktop, providing everything from clocks and application launchers to hardware notification and anything else the Plasma team might dream up. Extenders provide a simple way for applets to display additional information, as shown here. Panels provide a way to connect applets together, though this concept may be dropped in favour of applets locking together automatically.

Figure 1: An early extender concept

The Plasma team — a mix of core KDE developers, rising desktop development stars, and enthusiastic users — is making good progress. It has already integrated SuperKaramba into KDE 3.5 and ported existing components to Qt4, and is now reworking the frameworks to support later work.

Meanwhile, on the Plasma forums, applet ideas are being dreamed up, drawn, and discussed. Notable ideas include a slick semi-transparent extender, an embedded desktop search applet using Tenor, and even a limited but working demonstration of popular concepts using Flash. Ideas range from the radically different (such as this task basket) to the minor graphical improvement (such as this system tray animation).

The KDE 4 desktop may look similar to the KDE desktop we have come to know in the 3.x series. But, in terms of functionality and eye-candy, things will be quite different. For one thing, every component will have been designed with the big picture in mind, and with the assistance of artists and usability experts from the start. The desktop will also reflect the desires of the contributors to the Plasma forum, which is far more open than KDE’s developer mailing lists. By making use of new graphical capabilities in Xorg and Qt4, the desktop should look more beautiful.

Finally, Plasma will fully integrate with KHotNewStuff, a relatively new framework that allows KDE applications to download new plugins, extensions, and data from the Web. A secure, moderated selection of applets will be available and open to community submissions.

Opening KDE development to third-party developers

Making the desktop more attractive and usable is obviously a major priority for the KDE Project, but providing a development platform is equally important. There are hundreds of applications created by third-party developers on KDE-Apps.org, including many specialist tools for scientists, businesses, and designers, but takeup by independent software vendors (ISV) is still relatively low.

One way to increase ISV interest is to provide training. The Open Source Development Workshops to be held in San Diego in October will provide training for developers looking to work on the KDE development platform. But the fact that many companies are choosing to develop pure Qt applications, rather than making use of KDE’s powerful frameworks, makes some KDE developers think training isn’t the only problem that needs to be solved.

Martin Konold, best known for his work on Kolab and Kontact in recent years, is proposing a daring solution called RuDI — a compatibility layer in between KDE and Qt that would allow developers to write pure Qt applications that can take advantage of KDE’s powerful features. If a user runs the application in KDE then RuDI will make sure that the application can make use of KDE’s features like Tenor and network-transparent file dialogues. If the application is run on a machine without KDE then RuDI will ensure that it drops back seamlessly to using Qt’s functionality only.

Konold’s idea doesn’t stop with Qt and KDE. RuDI could be used by Gtk and GNOME developers to solve the problem of GNOME applications looking strange when running in KDE, and vice versa. RuDI could ensure that all applications inherit the behavior of the desktop environment they run in, no matter what programming language they are written in.

RuDI could solve several problems holding ISVs back from developing applications that utilize KDE’s features. First, it would provide a more stable Application Program Interface (API) that developers can link against (Qt), rather than KDE’s API, which has had three incompatible changes over the past nine years. Second, it could reduce the likelihood of ISVs linking statically against KDE libraries, causing compatibility and integration issues over time.

Finally, it would reduce the likelihood that developers use only Qt, creating applications that don’t really fit into the KDE desktop and fail to take advantage of KDE’s functionality. If completed, it will empower developers to use KDE’s attractive but complex architecture without these worries.

Concluding remarks

The work coming out of the KDE community is exciting, but nobody can be sure what technology will be present when KDE 4 finally appears. Tenor is still an idea with a vague expression and little code. The ideas being discussed on the Plasma forums are interesting, but still just ideas that need to be evaluated, subjected to usability tests, and then converted into working code.

Appeal has the potential to deliver a more usable, beautiful, and integrated desktop. Trolltech, the company that develops Qt, has expressed interest in RuDI but it will need a lot of work and cooperation to make it a reality.

All of these innovations, if completed, will make KDE an even better desktop environment. When next year’s aKademy rolls around, it will be interesting to see what kind of progress has been made.