The K Desktop Environment (KDE, see http://www.kde.org/) has already generated a lot of interest, and many individual users and institutions alike are using it as their desktop environment of choice. However, nothing is so good that it doesn't have room for improvement. Since the beginning, we have considered stability more important than sticking to announced dates, so there have been occasional delays when we considered KDE not stable enough for a release. That said, we hope to release KDE 1.1 after one or two beta versions by the end of 1998. This version will contain a number of bug fixes, the much sought-after support for ICQJava, more robustness in the HTML display code and a few new features such as configurable key bindings for the whole desktop. Originally, we had planned to release only bug fixes as version 1.0.1. However, the completed new features have been requested many times and we don't expect to have 2.0 stable for some time, so we want to include everything that is ready. This way, we can move on at full steam after 1.1 is released.

Figure 1. KDE 1.1 Desktop

Figure 2. KDE 1.0 Desktop

KDE 2.0, the next “official” version, will probably be out in late summer 1999, but this is still uncertain. In the meantime, we will also release a first alpha version of KOffice (discussed below).

We plan substantial rewrites and reorganizations of KDE for version 2.0. This will probably lead to snapshots that are unstable or don't compile, but as always, KDE follows the open-source model closely and makes daily snapshots available via the FTP site and the CVSup server. (CVSup is a software package for distributing and updating source trees from a master repository on a remote server host.)

Some of the new code that will go into KDE 2.0 belongs to the area file manager/web browser/networking code. Most of the new code is already written and just waiting to be committed to the CVS after the release of KDE 1.1. Changes include a complete rewrite of the file manager and the networking code which provides a great improvement over the current version, the ability to browse compressed archives and a complete overhaul of the user interface of the file manager. Related to this is the HTML widget currently in the process of being reorganized to make it more adaptable to new HTML standards and to provide better support for JavaScript and a free Java virtual machine. (kaffe, http://www.kaffe.org/, is a candidate if it supports standard AWT, Abstract Window Toolkit, programs by then.) Most of this is not just vaporware or simply plans for the future, but existing code, part of which is also available via the CVSup server with anonymous access.

Another program to be completely rewritten is the mail program KMail. The new version, dubbed KMail 2, will be more robust and flexible with respect to various attachments and feature IMAP support.

Of course, there is not only revolution such as complete rewrites, but also evolution as seen in the continuous development of existing features. More and more configuration modules are being added to the control center and we plan to provide more modules geared specifically toward system administrators. We hope to be able to support both LinuxConf and COAS (Caldera Open Administration System), but are definitely in need of more skilled developers to help in this area.

Another area of improvement is the drag-and-drop protocol where we will switch from our “homegrown” protocol to the XDND protocol, since it will likely become the future drag-and-drop standard on (at least free) UNIX systems and is currently supported by programs written with the JX toolkit. The GNOME developers have indicated that they will also support this protocol, possibly leading to a first point of interoperability between the KDE and GNOME programs.

We will also make use of some new features provided by version 2.0 of Qt, the toolkit used with KDE. Among these are themes and Unicode support. Themes are something I personally consider less important for a desktop aimed at improving productivity, but I know a lot of users want it and we aim to please. Note that some theme ability is currently in KDE (see e.g., http://kde.themes.org/), but the new code will extend this to single widgets within the application windows.

Plans have been made to tear the window manager engine out of the window manager KWM and put it into the library, so that there can be different window managers to implement a different look-and-feel and still provide the window manager functionality needed by a full-featured KDE desktop.

Unicode (see http://www.unicode.org/) is very important to gain acceptance in the Far East and other areas of the world with scripts containing more than 256 characters. Two Chinese localizations of KDE already exist, but these require a patched X server that combines two character codes transmitted for display into one. With Unicode support, such tricks will not be necessary, as the KDE message files can then contain 16-bit characters directly.

The usability of Unicode support is based heavily on availability of decent fonts for the script in question, something UNIX systems have traditionally been lacking. I have been looking at integrating the free True Type engine Freetype into KDE, but this is still in the beginning stages. (Contributions are welcome.) Another option is using a font server that supports True Type fonts.

Another area where work is being done is making KDE accessible for handicapped users. It is already possible to use very large fonts with KDE programs and especially to set such a large font once and for all for all KDE applications, so that people with slight vision impairment can use KDE programs, but this is not enough. We have had some success with voice-type software, i.e., software that allows users to navigate and operate the desktop and applications by speaking commands into a microphone. We are working with universities on leveraging their research results and making usable programs out of them. Another feature that falls into this category but has not been addressed yet is screen readers, i.e., software that reads out whatever is visible on your screen via your sound card and the speakers. While the necessary text-to-speech synthesis is a non-trivial problem (even though programs such as emacspeak show that it can be done in free software), screen readers become even more difficult to write when graphical user interfaces are involved, because a single text flow is no longer available as on terminal screens.

The topic most interesting to readers is the development of KOffice. KOffice (see http://koffice.kde.org/) is intended to be a complete office productivity suite like Microsoft Office or Lotus SmartSuite. It is CORBA-based (using the high-quality, freely available ORB Mico that makes good use of today's compiler technology) and uses the Open Parts as its object model. Open Parts is the master's thesis topic of one of our developers and provides a rich object model on top of the rather bare-bones CORBA standard, including addition of event services and event filtering to CORBA. Open Parts can even be used with non-KDE applications.

Not only the large KOffice applications will use CORBA, but this technology will also be used in other areas, including the panel which would then be better able to swallow other programs. On the other hand, adding CORBA compliance to a relatively small program like the panel means bloating it, and we still have to investigate whether this is truly worth it.

Figure 3. KPresenter

Figure 4. KSpread

Currently, KOffice consists of the following applications which, as I write, have different levels of usefulness. First, there is KPresenter (see Figure 3), a presentation program in the spirit of MS PowerPoint that has already been used for “real work” (like my KDE presentation at the last International Linux Congress in Cologne) and features a large number of blending effects. Then, there is KSpread (see Figure 4), a spreadsheet that already contains about 20% of the functionality of MS Excel and is easily extensible via scripts written in Python.

A recent addition to KOffice is KWord, a word processor aimed at smaller size documents like personal letters, as well as complete books. Besides normal word processing features, it also has some features known from DTP programs, such as Adobe FrameMaker. For large documents or those containing many formulas, it might be better still to use KLyX, a WYSIAWYG (what-you-see-is-almost-what-you-get) document processor that uses LaTeX as its formatting engine and is based on its older brother, LyX. KLyX is not yet as fully integrated into the KOffice concept as the other applications, but hopefully it will be in the near future.

Figure 5. KIllustrator

Figure 6. KFormula and KImage

The KOffice application that is probably most advanced at the moment is KIllustrator (see Figure 5), a vector-based drawing package. It features a lot of drawing tools and is very usable. Two other applications of KOffice are KFormula (see Figure 6), a mathematical formula typesetter; and KImage, a smaller image-manipulation program. Finally, there is KChart, a component for drawing business graphs such as bar charts and pie charts; and KOrganizer, an organizer program in the spirit of Lotus Organizer that is quite usable and sports many features and different views.

Since all KOffice programs are based on the Open Parts framework, they can all be embedded into each other. You can nicely embed a spreadsheet document into your word processor document and beef the whole thing up with a vector drawing done with KIllustrator. This embedding also features in-place activation with dynamic menu bars, and unlike other embedding technologies on some platforms we like to hate, it is quite stable.

We are very aware that for Linux to become a viable alternative to Windows or the Macintosh, it must feature a consistent easy-to-use desktop and also have an office productivity suite that need not (or should not) be as bloated as Microsoft Office, but definitely needs the features used on a daily basis and must be able to read common document formats. Unfortunately, Microsoft Office formats are not well-documented. Still, with the help of the work done in LAOLA (library for Microsoft structured storage files), we hope to be able to support at least some of them. Even though I think this is a boring task (if somebody thinks I am wrong here, you are welcome to help with this project), we will also write an RTF reader and writer, and I have already successfully imported some FrameMaker documents via my homegrown filter into KWord. Whether other formats (such as WordPerfect, StarOffice or the Lotus SmartSuite) will be supported depends on two things: whether the respective manufacturers will make their format documentation available and whether someone volunteers to do the work.

As you can see, many things are happening in the KDE world and development is occurring faster than ever. As with all free software projects, we can be only as good as the people who support us, so if you are interested in GUI hacking, writing file-format filters or any of the other topics I have mentioned (or something completely different that fits into the overall KDE concept), don't hesitate to contact us (see http://www.kde.org/ for contact information). This is truly an exciting project to be in.