KDE—K Desktop Environment

The KDE team is working full steam on the next release of the K Desktop Environment which is planned for spring 2000, so it is time to look at what the new version will have in store.

When you first install one of the beta releases and use a plain old setting, you will probably not notice much difference between KDE 1.1 and KDE 2.0. However, the more you explore, the more you will find things that have changed. Also, many changes have been made under the hood.

Let’s start with some of the core components. As a programmer, you might be interested to hear that the library interface has been cleaned up. As a user, this probably won’t interest you half as much as the fact that the web browser now supports JavaScript and Java. The Java support is not bound to any particular implementation of the JVM; you can use any fully compliant implementation. We do our testing with the blackdown port of the Sun JDK, but barring some bugs, you should also be able to use kaffe, for example. Also notable is that not just the HTML widget and applications can use Java—any KDE application can now embed a Java applet in its windows. JavaScript support was partly available in KDE 1.1 already, but it was so rudimentary no one really used it. KDE 2.0 features an all-new implementation that is much more complete; it enables you to view 90% of all web pages using JavaScript.

Speaking of the browser, the whole HTML widget, i.e., the part that is responsible for all HTML display, has been completely rewritten. In particular, the display of tables as well as the speed has been greatly improved and the internal structure now conforms to DOM, the Document Object Model put forth by the World Wide Web Consortium (W3C). The HTML display component is fully HTML4-compliant, and—if the patent dispute between the W3C and Microsoft is sorted out—will most likely support CSS1.

The KDE web browser/file manager has been renamed Konqueror. The name choice is obvious: history tells us the conqueror always comes after the navigator and the explorer. It has also become more flexible. The KDE PostScript viewer kghostscript and the KDE DVI viewer kdvi can now be used in Konqueror. The same goes for the information and help page viewers, and more can be easily integrated in the future.

Two more core components have been completely re-implemented: the window manager, now called kwin, and the panel, now called kicker. kwin is much more flexible than the old kwm, thanks to its very modular design. For example, it will be possible for applications to ask the window manager for decorations of internal windows. This is useful for applications like StarOffice that use the “window manager in a window” paradigm. Until now, these applications have had to emulate the look-and-feel of one window manager, which was awkward for users who used another manager on their desktop. For KDE 2.0, this feature is still disabled, because it wasn’t tested enough. However, the code is there and will make its way into one of the following releases. The author of kwin, Matthias Ettrich, is working with other notable window manager authors on a common window manager specification (the so-called NET protocol), so that window managers on Linux will be easier to exchange in the future. As with KDE 1.1, you can run KDE with window managers other than kwin, but you may lose some functionality.

As for kicker, the new panel, it will be extremely easy to write applets that either run inside it or stand alone. This was already possible with kpanel, but with kicker, the burden for the developer has been eased even more. Also, applications can now dynamically add or remove submenus in the K menu at runtime. The taskbar can be included inside the panel (many people wanted that), and the whole panel can be dragged around on the screen. It is much more configurable than the old one.

So far, KDE has had the reputation of being stable and solid, but a bit boring when it comes to looks. This has completely changed. KDE 1.1.2 already contained some theme ability and a theme manager; KDE 2.0 can be graphically customized in any way you like—the possibilities are limitless (see Figure 2). Everything from a very basic and subdued look to a completely Gothic desktop is possible. It’s up to you and your artistic capabilities, but of course, there are many ready-made themes for you to try (see http://kde.themes.org/).

When starting the development of KDE 2.0, the KDE team was focusing on using CORBA, the Common Object Request Broker Architecture, a middleware framework for distributed object communication. However, during development it turned out that while CORBA is a cleanly designed architecture useful for large and high-latency things such as corporate databases, it is not so well-suited for tasks such as user interfaces where speedy responses are needed. There are several reasons for this. CORBA is distributed in nature, which is very good if you need distributed objects, but more of a burden than a gain if you don’t need them—and you don’t need them in an office suite. Also, CORBA is too static. In a desktop, objects and applications come and go all the time. This is very hard to track reliably with CORBA.

Thus, the KDE team had to find something else in two areas. KOffice needed a new underpinning for embedding applications into each other and general desktop communication between the control center and the applications. Something more lightweight was needed, and this led to two new inventions that are now used in KDE 2.0: KParts and DCOP.

KParts is the new object framework used in KOffice for embedding application windows into each other. You can, for example, embed a spreadsheet window from KSpread into the word processor window from KWord, just as you could with the previous development versions. Since all KOffice components are now simple shared libraries and the whole document is handled in the same process, this happens much faster and smoother than before. Actually, the previous embedding framework was so slow (and buggy) it was hardly ever used. With KParts, there is no speed difference between working on the container part (the word processor in our example) and the embedded part (the spreadsheet in our example). In addition, embedded views can now be tilted, twisted, rotated and sheared, something which to our knowledge is not available on any other platform. I’ll talk more about KOffice a bit later in this article.

DCOP, which stands for Desktop Communication Protocol and is pronounced “dee-cop”, is the other new communication facility. DCOP uses a standard mechanism, ICE from X11R6. ICE was written mainly by the X developers to implement session management, but as it turned out, it can also be used for other things. Since it is standard, available in all X11R6 implementations (including XFree86), fast and lightweight, it was a natural choice. For those interested, communication between processes in ICE is done via either UNIX domain sockets, TCP/IP sockets or DECnet. DCOP is just a thin layer on top that handles the marshaling of data and makes sure all communication streams reach their destination. You can imagine DCOP as a traffic cop who stands in the middle of a road crossing and directs the cars into their lanes, so that everyone reaches their destination, no accidents occur and no passengers end up in the wrong cars. (Okay, this is where the analogy breaks down.)

DCOP is used in KDE to unify the different communication means, like X atoms for communication between the control center and the application or TCP/IP sockets. In KDE 2.0, developers need to learn only about DCOP and can forget about X atoms and other communication means. Also, since DCOP is based on the X11R6 standard ICE and is open and documented, it is not bound to KDE. Non-KDE applications that wish to take part in these communication channels can either link directly to the KDE implementation of DCOP or easily implement a compatible implementation themselves. Also, there is already an XML-RPC-to-DCOP bridge, and people are working on a general IIOP-DCOP bridge as well. XML-RPC is especially interesting, because it will allow scripting the whole desktop from just about any language you like, including /bin/sh.

This does not mean KDE has completely dropped CORBA; the KDE team just has a much more judicious view on where CORBA is useful and where it is not. There are areas where CORBA is still deemed useful; one of them is the new KDE multimedia framework aRts.

In the current version, aRts is an audio server and mixer that can handle many different incoming audio streams, manipulating, mixing and outputting them to an audio device like an ordinary sound card. At the KDE developers’ conference KDE II in early October in Erlangen, Germany, aRts’ main author Stefan Westerfeld gave a very impressive demo of aRts mixing two MP3 streams: one of them manipulated with additional sound effects and one synthesized in real time from the MIDI events being played on a MIDI keyboard.

Again, CORBA has to be used judiciously. For a full-blown multimedia application like Brahms, the KDE synthesizer, CORBA is the right tool. For a non-multimedia-oriented application that just wants to play a warning beep when something goes wrong or a lengthy background task is finished, CORBA is way too much, especially since this application would have to link to the full CORBA machinery just to play its beep. This is why aRts also provides a lightweight, raw TCP/IP-based mechanism for playing simple .wav files. (The applications cannot do this themselves because on Linux, only one application at a time can open a sound device.) Also, the KDE team is evaluating another alternative, MCOP, the Multimedia Communication Protocol. By the time you read this, it may have turned out that MCOP is better suited for this task than CORBA, and if it is better, then it will probably already be in use for aRts.

Now let’s go back to some more basic components. The KDE configuration files have always been pure text files. This had the advantage that nothing could go corrupt—you could, if necessary, edit the text files by hand or use a Perl script to change the configuration files of a few hundred users at once. So, text-based configuration files are desirable. However, a typical KDE desktop has hundreds of these files not only for each application, but also for each MIME type, each service type and so on. This led to slow application startup, because all these files had to be opened and parsed. The solution to this is KSycoca, the KDE system configuration cache. KSycoca is a sort of daemon running in the background and watching for changes in the configuration files. KSycoca reads all configuration files and builds a binary database which can be accessed much faster than the individual, text-based files. However, those are still the authoritative source of all configuration information, so you can edit them by hand or by scripts. In case anything goes wrong with KSycoca, it can simply dump its database, because it is nothing more than a cache and contains no information unavailable elsewhere. Compare that to operating systems with binary registers which can get messed up so badly you cannot boot up your operating system!

We have already talked about some internal changes in KOffice. The development of new features is also progressing. Implementing import filters is a very hard task, but Werner Trobin has already made some progress, so there is hope that KWord (see Figure 4) will be able to import Word 97 documents in the not too distant future. KPresenter (see Figure 5) now supports presentation templates, and KSpread (see Figure 3) has also received many more features too numerous to list here—check it out yourself. However, there are (besides the “old” applications KSpread, KWord, KPresenter, KIllustrator, KChart and KFormula) two new kids on the block. KImageShop is a multi-threaded image-manipulation program that aims at being as powerful as the GIMP, but easier to use. Also, KImageShop has a very clean C++ design that will make extensions much easier. KImageShop will not be ready for public use any time soon, but shows some very promising results. Finally, kdatabase is a database front end that aims at making database power more accessible for the end user, and of course, features embedding into other KOffice applications.

KDevelop, the KDE Integrated Development Environment (IDE), is one of the sub-projects that is perhaps making the most progress. By the time you read this, version 1.0 should be out, and it features, among other new things, support for Objective-C and a very nice class tree view. KDevelop’s development is a bit decoupled from KDE, i.e., it does not follow the same release plans. However, the KDevelop people put much effort into ensuring KDevelop always works with the current KDE versions.

Another important change comes from the documentation team. All the documentation is moving from the LinuxDoc SGML DTD to the more powerful and professional DocBook DTD that most professional publishers use. This move is also being executed by the LinuxDoc people, so that DocBook will become the pre-eminent standard for Linux documentation in the future.

All those changes, new features and new applications, impressive as they may seem, are simply nothing against the one true KDE killer application that has appeared recently: ky, the KDE implementation of the classic UNIX yes tool!