X11 Desktop Environments (KDE and GNOME) - Part II

 and  , IT/PDP

Abstract

This is the second part in a series of three articles dedicated to the KDE and GNOME desktop environments. In the first part (), we explained what a desktop environment is and what its main components are (like the panel, control center, file manager etc). In this article, we will analyze the desktops from a more technical point of view, looking in more detail at the internal architecture, usage of protocols, etc.

Basic KDE architectureIn the picture we can see the basic architecture of KDE. The first two layers Xlib and X Toolkit Intrinsics are two low level programming APIs included in X Windows. Using these libraries we do not have dialog elements (widgets), so the user interface of the X applications are not homogeneous between them. But, in other operating systems like Windows and MacOS, the applications have a homogeneous user interface. Thus we need to include another higher level graphic library, the Toolkit (in case of KDE the Qt), which give us the widgets and, in general, an homogeneous and uniform aspect for all the applications that use it. The KDE libraries, KDElibs, are built on the top of Qt though they can still make use of the X's APIs when they need to make lower level operations. In the top layer we have the KDE applications which are built using the KDE and Qt libraries. 
GNOMEThe GNOME architecture is a bit different from KDE's. The GNOME libraries are the highest level. GTK+ with its two parts, GTKand GDK, comes next. The GTK level provides an object model for C and a UI toolkit with the basic widgets to provide the generic basis for a GUI. GTK depends on GDK, which is a low-level wrapper around Xlib, the library directly talking to the X server. Everything (except for Xlib) depends on GLib, which is a very useful C library with many utility and portability functions as well as a range of easy to use containers for C. 
Why use KDE and GNOME libraries?Why not just program directly with a GUI toolkit such as GTK+, Motif, or Qt, without any other libraries? By using the KDE and GNOME libraries, you can save a lot time, because a lot of code is already written, and a lot of widgets are already predefined. These widgets will also be consistent in both look and feel across all applications using the KDE and GNOME libraries. And code sharing among applications reduces your memory requirements, because the code will be part of the shared library rather than loaded into memory for each application. But KDE's and GNOME's greatest advantage is that the library lets you focus on the real functionality of your application; you don't have to spend your time writing and debugging the user interface.Qt and GTK+GNOME and KDE are both based, as already said, on a graphical toolkit which provides the basic set for graphical operations. The toolkit used by KDE is Qt 1.42. KDE 2.0 will be based on Qt 2.0.

Some characteristics of Qt:

• Qt has a modular design and a strong focus on reusable software components.
• Ported to most Unix flavours, but also for Windows.
• Use of OpenGL supported.
• Very good On-Line documentation.
• An important number of applications are available, many of them part of the KDE project.

The weak points are:

• Qt 1.42 did come with a Open Source license; this changes for Qt 2.0 (QPL license).
• Only three languages are supported (C++, Python and Perl).
• Themes are not available under Qt.
• Currently, there's no support for the XDND Drag&Drop protocol.

The GNOME project decided to use GTK+ as their graphical toolkit. GTK+ was initially developed for the GIMP tool (a PhotoShop-like application).

Positive characteristics of GTK+ are:

• Support for 16 different languages, including C/C++, Pascal, Perl, Python.
• Support for themes.
• GPL License.
• Support for both the Motif and XDND Drag and Drop protocols.
• Use of OpenGL together with GTK+ is supported.
• Also, many applications are available which use this toolkit.

The weak points are:

• Insufficient documentation.
• Bad portability to Microsoft Windows.

Information exchangeApplications have to provide means for communicating with other peer applications. A simple example could be the use of copy and paste of text segments, whereas there are other more complex operations such as inserting an image created with a paint program into a spreadsheet. 
There are several communication mechanisms available under X11. The most important are:

• The ICCCM mechanisms (Inter-Client Communication Conventions Manual).
• Drag and Drop protocols.
• Session Management protocols.

ICCCM MechanismsICCCM is a standards collection where the following information interchange mechanisms are defined: Primary Selection, Secondary Selection, Clipboard Selection and Cut-Buffers. X-based applications can communicate within each other using Selections which allow to select and copy text regions from one application to another. The primary selection is used e.g. when selecting a text region with the left mouse button under Netscape. The secondary selection can be used independently of the primary selection; emacsuses the secondary selection for erasing text without changing the cursor position. The Clipboard Selection gets activated when cutting or copying text into a special buffer (the clipboard), the contents of this buffer can be transferred afterwards to another application. The xclipboard application allows you to check its contents. Whereas the selection mechanisms establish a link between a source and a target application, the Cut-Buffers are based on a common area provided by the X server. This way, a X client may introduce information into a cut buffer which can be retrieved later on by any other X client. X allows use up to eight cut buffers. With the xcutsel tool, the contents of a primary selection can be copied into a cut buffer or vice versa. 
Both KDE and GNOME do support those protocols and mechanisms as they're defined at the X layer.Drag and Drop ProtocolsThe ICCCM mechanisms only allow to exchange plain text regions. For any other objects (i.e. images or rich text sections), several Drag and Drop (DND) protocols have been defined which allow you to select and then transfer those objects within applications. The basic requirements for all DND protocols are:

• Provide visual feedback to the user during the drag.
• Allow the target application to choose whatever data format it prefers from among all the formats that the source can provide. Thus a word processor might tell a image program to provide a picture in a specific format in order to avoid useless conversions.

In addition, it must be efficient so that the visual feedback does not lag behind the user's actions, and it must be safe from deadlocks, race conditions, etc. 
Two well known DND protocols are the Motif DND, provided with the Motif toolkit, and OffiX. Motif DND implements correctly all DND functionalities but it is a rather complex protocol. LessTif (a free Motif clone) implements also a simplified version but generally, Motif DND is rarely used outside Motif-based applications. The OffiX protocol, used by applications like ImageMagick or Xemacs, is fairly simpler to use than Motif, but also less powerful as it lacks some characteristics like visual feedback or choosing the data format by the target application. 
The XDND (X Drag and Drop) protocol is a new standard which implements all DND requirements but in a more lightweight fashion, overcoming the problems with Motif andOffiX. XDND has been spreading wide since its creation and is supported both by GNOME and KDE and their underlying libraries (GTK and Qt), by some window managers (like enlightenment) and by many other applications.Session ManagementThe purpose of session management is to provide users a possibility to save and restore their whole working environment or session. A session is a collection of applications, all of them having an internal state. This state may be the name of an open file, a displayed image or the score of a game. When quitting a session, the states get saved and restored the next time the user logs in, retrieving his working environment the way he left it.

Every application that is session management aware connects to one special server: the session manager. A session manager sends commands to his clients telling them to save their state or to terminate. A client must provide the session manager with all information that is needed to restart the client in the same state as it is running now. The session manager's task is to take care of this information and to use it when restarting a session. In order to distinguish all clients, the session manager assigns them a unique identifier: the so called client id. Currently, two different protocols for the Session Management are available. On one hand, the ones collected in the ICCCM manual under Obsolete Session Manager Conventions (described in the ICCCM appendix C); and on the other hand, the ones defined by the X Session Management Protocol. KDE uses an extended version of the Obsolete Session Management Protocol, whereas GNOME uses the X Session Management Protocol.

Documentation systemsDocumentation is perhaps one of the most important features for users. However, it is a subject which is quite often forgotten. KDE and GNOME help-browsers are able to work with HTML files. An emerging standard is to use DocBook SGML. SGML stands for Standard Generalized Markup Language, and is a system for organizing and tagging document elements. DocBook is a document definition based on SGML, and defines how the tags must be interpreted by the application that displays the document.

In KDE, application documentation is made in HTML, although they are starting to use DocBook SGML. For the source program documentation a program named KDoc is being used. KDoc is a documentation tool initially developed for documenting KDE libraries. KDoc extracts documentation and information of classes of C++ header files. Then this information is used for making HTML documents, LaTeX documents or man pages. It also generates cross references when appropriate.

In GNOME, application documentation is made normally using DocBook SGML which is then translated to HTML. For documenting libraries, the gtk-doc application is used, which reads C header files and generates a template which is filled in by the authors. These templates can be translated to DocBook SGML and from this to HTML, LaTeX or man pages. 

Programming environmentsBoth KDE and GNOME are working on rapid application development toolkits. The KDE team is working on KDevelop, an IDE (Integrated Development Environment) which offers you on-line access to all KDE and Qt documentation, as well as a friendly editor and application template generation engines. KDE tools include also KDDL (KDE Dialog Definition Language) and KDE SDK (Software Development Kit). For GNOME, Glade (a visual user interface builder a la VisualBasic) and gIDE are being developed. 
Coming soonIn the next (and last) part of this article, we will analyze in more depth the internal architecture, including the usage of CORBA and compound documents, and how to install those desktops at CERN. 

More information under  
Table 1. Technology overview

	KDE	GNOME
Toolkit	Qt 1.42 (Qt 2.0 in v2.0)	GTK+ v1.2.7
Toolkit Programming Language	C++	C
Toolkit License	Qt Free Edition License in Qt 1.42. QPL in 2.0	LGPL
Toolkit Language Bindings	Python, Perl	Ada 95, C++, Dylan, Eiffel, Guile, Haskell, JavaScript, Objective C, Objective Caml, Objective Label, Pascal, Perl, Pike, Python, TOM.
Toolkit support graphics 2D/3D through OpenGL/Mesa	Yes	Yes
Toolkit support themes	No	Yes
Desktop License	LGPL/GPL	LGPL/GPL
Support ICCCM Mechanisms	Yes	Yes
Drag and Drop Protocol	KDND in KDE v1.1.2. XDND in KDE v2.0	Motif, XDND
Session Management Protocol	Proprietary in v1.1.2. XSMP in v2.0	XSMP
Theme support	Yes	Yes
Compatible Window Managers	KWM, WindowMaker, BlackBox, Enlightenment, fvwm.	Enlightenment, WindowMaker, fvwm, IceWM, SCWM, gtkWM, etc.
Application documentation	HTML, DocBook SGML	DocBook SGML
Library Documentation	KDoc	gtk-doc
Language Bindings	Tcl/tk, Python, Java, Perl	Java, Python, Dylan, TOM, C++, Ada 95, Perl

About the author(s):

Victor Robles visited CERN in 1999 as Technical Student; his researchs within the desktop environments were so remarkable that an spanish computing maganize of national reach accepted publication of his articles.

German Cancio works in the PDP/OSE section and was recently awarded an staff contract.