KDE-Programming

Linux for all!

by Kalle Dalheimer
Linux Magazin

Translated by David Sweet

November 1997

The goal of the KDE project is to simplify the use of Linux. In this series of articles the author shows how one can use KDE and program KDE applications.

Before we go into the coding, however, some discussion is in order. I describe here the design priciples of KDE and tell you how to contact us. Then I describe the project organization and finally comment on the rest of this series.

From the programmer's point of view, one of the central features of KDE is the use of the Qt class library. We are often asked, and it is natural to ask, why we have selected Qt (and not for example wxWindows, Motif, or gtk). The respone is rather simple: Qt is simpler and technically far superior to all other toolkits, both in quality of the classes provided and the quality of support. (It is not uncommon for a user of the free license to receive a support responses in twenty minutes -- a response time one rarely finds from Usenet; with some commerical UNIX manufacturers, I would be pleased to receive a response in twenty days...) The Qt reference documentation is also excellent. Other libraries which were discussed were wxWindows (the programming of which, in our opinion, was too tedious, and, at the time, the future of wxWindows was somewhat in question (although it is no longer)), and gtk (which was stil too incomplete and is C-based). The descision to use Qt was not determined from the outset. Matthias Ettrich, the project founder and leader, had proposed Qt, but its use was initially debated on the mailing lists. The quality of Qt determined the final verdict. Motif, incidentally, was at no point under discussion -- anyone who has developed a large project with Motif will understand why.

Critics of Qt and KDE are often bothered by the use of C++ as the language of implementation because this might exclude many potential developers. I do not have concrete numbers, but I nevertheless have the impression that the transition from C to C++ can be carried out, if slowly. C++ is as easy to learn as any other programming language and a free compilier is available (that is sometimes problematic, but one can work around these problems easily.) I am convinced that one wastes more time if one attempts to execute an entire project with an unsuitable programming language than if one first learns a suitable lamguage and then proceeds with the project. KDE may also be the incentive for some to finally learn C++. Surely there are languages which are superior to C++, but if one considers program start-up time, availability of development tools and libraries, and available literature, then it is difficult to find a better language for a large project such as KDE.

Since there are surely some who are interested in KDE, but who are unfamiliar with Qt, here are some of the main points which make Qt appealing:

The Qt Signal/Slot mechanism, which has recently found itself imitated in other toolkits, is very practical and, to my knowledge, first used in Qt. This mechanism offers two advantages over conventional procedures for the handling of event propagation, such as Callbacks or virtual methods: on the one hand it is type-safe, and on the other hand it enables genuine component-based developing, i.e. a component need not know by whom they are being used, and its users only need to know what services the component provides. Instructions for programming with Signals and Slots are available in the Qt documentation (see below), I will mention only relevant points herein.

A few words about licenses: You'll find information about the often misundersood Qt license in the sidebar "KDE, Qt, and the Qt license." Let me make a few points here, however, about the licenses used in KDE. KDE code is neither under LGPL or the GPL. Unfortunately, the applicable licenses are scattered throughout the source code, but there are some rather good rules of thumb. When in doubt, it is good to contact the author. Everything in the kdelibs package was written by and for the KDE project and is not under LGPL. Nevertheless, the libraries in kdelibs can be used for a commerical project with one caveat. The GNU gettext, which is used for interationaliztion, and is under GPL, must be replaced with the commercial software maker's own implementation. This situation is somewhat unfortunate, but we will not put much effort into changing it since the kde libraries are primarily meant as a base for KDE applications. If someone were to make a gettext-equivalent available under LGPL, or some other license freer than GPL, we would gladly switch, otherwise things will remain unchanged. The libraries in the kdesupport package are provided "as is". They are supplied by us to a large extent because some distributions ship either with outdated versions of the software contained in kdesupport, or with no version at all. The licenses of the respective libraries apply. The KDE applications should be, nonetheless, under the GPL; in case of doubt, an email to the author or a look into the source code is helpful.

Section 1: KDE in Action


Goals of the KDE Project

The primary goal of the KDE project is to create an easy to use, consistent, visually appealing desktop for Linux and other versions of Unix. The chaos resulting from the differing looks and feels of the various window managers, xterms with Athena widgets, programs with Motif widgets, workman with xview widgets, etc. will be replaced by a consistent desktop. To this end the KDE project supplies not only a window manager and desktop manager ("panel") but a UI wrapper and new implementations of well-known Unix tools such as xterm (replaced by kvt), ghostview (replaced by kghostview), and xmcd (replaced by kscd). All of these programs use the Qt widget set and thus have the same look and feel. The standards for keyboard accelerators and menu entries are only partially developed at this time; we have experimented with different forms and are about to settle on standards for all KDE applications. By adhering to these standards, application developers will be supported by the KDE libraries. These libraries supply widgets which are absent from Qt, or which are not well-suited to serve as KDE widgets. A large part of the KDE functionality is gained simply by deriving from the class KApplication.

The KDE-RFC, while somewhat outdated, describes the distinguishing characteristics of a KDE application. Additionally, in the last month a KDE file system standard was developed which tells KDE applications where to place auxiliary files such as icons or help files. The idea is to keep all KDE files (except for users' personal configuration files) in one file tree. The preferred root for the tree is /opt/kde, but /usr/local/kde is also a likely place.

Naturally we cannot port all Linux applications ([??? - and also Kommandozeilentools]) to easily operated KDE tools. We are dependent on the support of the respective developers. But porting is facilitated by KApplication and the, to a large extent automatically operating, configuration system KConfig and KTopLevelWidget, which, among other things, positions toolbars.

We document all classes of the KDE libraries to make them as easy to use as posssible for the developer. Dissatisfied with available documentation-generating tools, we developed kdoc which, similar to Javadoc, can produce HTML documentation files from the structured comments of a class declaration. I will discuss the use of kdoc on your own classes in a future installment of this series.

Figure 2: One of the many KDE applications


KDE applications should be network-transparent. That means not only that X11 is used as the underlying window system, but that a user should be able to open a file on one of the local file systems just as easily as from the Internet. The underlying mechanism has been present almost since the beginning of the KDE project; I will discuss this in a future installment of this series. Until now one has had to type in a URL, however by this time of this printing, a new file selector will be available in the KDE libraries which will be more user-friendly.

KDE applications should -- where possible and meaningful -- support drag-and-drop. Many KDE application already serve as drop targets, since there are classes in the KDE libraries which facilitate this, but so far only the file manager, kfm, serves as a drag source; there is still some work to be done in this area.

Prerequisites for KDE programming

What do you need to know to program for KDE? First of all, naturally, a knowledge of C++; however it is not necessary to be a C++ professional. For those who are new to C++, I would recommend "C++ und beherrechen/C++-Primer" by Stan Lipppman [1] or "C++; The Core Language" by Satir and Brown [2]. One's primary reference would naturally be "The C++ Programming Language" by the inventor of C++, Bjarne Stroustrup (soon to appear in a new edition). [2]. One looking for a more advanced text should see "Effektiv C++ programmieren" by Scott Meyers [4] ( at present also available in an English version [5]). Additionally, "Entwurfsmuster" by Gamma, Heml, Johnson, and Vlissides [6] is very good.

Knowledge of X is not necessary for the fundamental mode of operation since Qt takes over most of the functionality one would need. Only one programming the terminal program, kvt, or the window manager, kwm would need knowledge of X; in the case of kwm a detailed knowledge. In any case, one needs to know Qt, but, again not be a professional. Qt comes with very good reference documentation and for those who, like me, prefer printed documentation, there is a Postscript version available for download. Included with Qt is a tutorial which, however, only treats some sections of Qt. I would reccommend looking at the programs in the examples directory of the Qt source distribution as well as the tutorial.

Needed software

Only a small amount of prerequisite software is needed to participate in the KDE project. For example, it is not even necessary to have a Linux distribution (what a thing to say in Linux-Magazin!), KDE can be used on many other Unix systems. Part of the development even takes place under Solaris, but KDE runs on, for example, Irix or Linux/Alpha. Naturally a C++ compiler is necessary, preferably one which supports Templates. Since most KDE developers use GCC, this is sufficient and always useable. Finally you need the Qt library and header files. You can find this all at http://www.troll.no/ both in .rpm and .tgz format. If your distribution already contains Qt, you should be sure that it is the current version, v1.3, which recently appeared.

Of course, you'll need the KDE code. At http://www.kde.org/ you'll find .rpm, .deb, and .tgz format distributions. These, however, are not always up-to-date. If you want the most current version, you should go to ftp://ftp.kde.org/pub/kde/unstable/distribution/tgz/current. Here all of the most current code is supplied directly from the KDE CVS repository. Rather than require a complete download to acquire each change, patches are supplied in the directory ftp://ftp.kde.org/pub/kde/unstable/distribution/tgz/sdiffs. If you'd like to automatically receive daily patches, you can subscribe to the mailing list patches@kde.org. With the list server's acknowledgement comes a piece of code for your .procmailrc which enables you to automatically unpack and decompress the patches. (note: the patch is not automatically applied, you still must do this by hand). It may be that these daily updates are buggy or don't even compile. So those of you who want to be on the "bleeding edge" should be able to deal with such code and perhaps be handy with a debugger.

Here is a brief description of the .tgz packages available on the FTP server. They reflect the organization of the CVS repository:

Don't forget, however, that these are only some of the KDE appications. You'll find many more in the unstable/apps directory on the FTP server. Look through it carefully -- there are some gems in there!

Installing the packages

The installation must be done in the following order: kdesupport (if needed), kdelibs, kdebase and then the others can be installed in any order. It is, of course, possible to install a single application from one of the packages without compiling all of the applications in that package.

Basically, each package is installed with the following commands:

where the last command must be executed as a superuser. The configure script accepts the usual parameters; --with-prefix= installtion location, for example. There are others: Some packages have more parameters. You can type ./configure --help for a list.

The CVS respository

The KDE project maintains a central CVS repository, which has been mentioned several times. It contains the master source code from which the packages or diffs are generated automatically, or semiautomatically. Each developer can request to place an application in CVS and get an account for dealing with the application's source. Typically a developer uploads a program to the FTP site. If this program turns out to be central to the project or in some other way important, or the developer requries it, then the sources are placed in the CVS repository. We hope to, in the long run, administer to KDE programs in the CVS as much as possible. CVS is simple to use, but a KDE specific mini-HOWTO is available if needed.

Contact

There is a whole set of KDE mailing lists; you can find out about all of them on our WWW server. The most important list for developers (which has a bearable amount of traffic and a high signal/noise ratio) is kde-devel@kde.org. To subscribe to the list, send an email to devel-request@kde.org with the text "subscribe" in the message body. The language used on these lists is English, which prevents allows all developers to participate in and understand the discussion. [This is also the motivation for this translation, incidentally! -- DS]

How to help

On the WWW server http://www.kde.org/ you will find information on which projects need doing. Additionly, we need people to help with documentation of the individual programs and to take part in alpha/beta testing by reporting bugs and helping to track them down. Even a stack trace can be a helpful part of a bug report to a developer. Bug reports should go to bugs@kde.org with a CC: to the appropriate developer.

What's next

In the next installment I will discuss how a simple KDE application looks. We will learn about KApplication, KConfig, and KTopLevelWidget. In later installments the following topics will be treated (among others):

If you are intersted in other topics, please write to me at the email address indicated below.

Literature

[1] Stanley B. Lippman: C++ lernen und beherrschen. Addison-Wesley, 1992. ISBN 389319-375-8.
[2] Gregory Satir und Doug Brown: C++: The Core Language. O'Reilly & Associates, 1995. ISBN 1-56592-116-X.
[3] Bjarne Stroustrup: The C++ Programming Language, 2nd. ed. Addison-Wesley, 1991. ISBN 0-201-53992-6.
[4] Scott Meyers: Effektiv C++ programmieren. Addison-Wesley, 1995. ISBN 3-89319-816-4.
[5] Scott Meyers: More Effective C++. Addison-Wesley, 1996. ISBN 0-201-63371-X.
[6]Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster. Addison-Wesley, 1996. ISBN 3-89319-950-0.
[7] Christian Kirsch: Klassenstärke - C++-Klassenbibliothek für X und Windows. iX 6/1997.
[8] Christian Kirsch: Klein, Durchdacht, Effektiv. iX 9/1997.
[9] Kalle Dalheimer: Oberflächliche Eleganz - KDE, ein neuer Desktop für Linux und andere Unix-Varianten. c't 8/1997.
[10] Eirik Eng: Qt GUI Toolkit - Porting graphics to multiple platforms using a GUI toolkit. Linux Journal 11/1996.
[11] Matthias Ettrich: Fensterln in C++ - Qt: Programmieren mit dem Application Development Framework. PC Magazin DOS Spezial 4/1997 - Linux.
[12] Kalle Dalheimer: Die Spinne im Netz. Softwareentwicklung, 7-8/1997.
[13] Kalle Dalheimer: Technischer Troll. Softwareentwicklung, 10/1997.

Copyright 1997