X11 Desktop Environments (KDE and GNOME)- Part III

,  , IT/PDP

Abstract

This is the last in a series of three articles comparing the two emerging desktop standards, KDE and GNOME. Three main subjects will be addressed: interprocess communications and CORBA, API descriptions, and installing the desktops at CERN.

X11 Desktop Environments (KDE and GNOME - Part III)

This is going to be the last article in a series of three comparing the two emerging desktop standards, KDE and GNOME. Three main subjects will be addressed: interprocess communications and CORBA, API descriptions, and installing the desktops at CERN. 

IPC's and CORBAIn the last article, we described what information exchange protocols are available for GNOME and KDE, like drag and drop, ICCCM, etc. We are going to have a look now by what means this information exchange is carried out. In the UNIX world, interprocess communication (IPC) has been traditionally done using pipes, sockets and RPC's; CORBA has made its appearance over the last years.PipesUNIX offers the possibility of using pipes to share data between processes. A well-known UNIX command sequence like 'ls -l | more', concatenates two processes ('ls' and 'more'), conducting the output of the first process to the input of the second one. Nevertheless, the functionality of a pipe is limited. They are unidirectional, which means that a process can write into a pipe and another one can read out of it, but for a bidirectional communication, two pipes have to be created. It's a very low level protocol, data being read or written word by word. It two applications wish to interchange complex data, they have to agree on a common data structure and format. SocketsLike pipes, sockets are low level mechanisms and word oriented. Sockets allow you by using a network protocol (as TCP/IP or IPX) to transparently communicate processes running on different machines. The main difference with pipes is that sockets allow bidirectional communication. Nevertheless, data structure must be defined at application level, as with pipes. Sockets are nowadays a must when using standard internet protocols like FTP, HTTP, etc. RPC (Remote Procedure Calls)One of the major problems with pipes and sockets is the lack of a standard for interchanging data structures and for remote function activation. Applications should shouldn't have to take care about how, but about what data structures are transmitted. RPC does provide this encapsulation. RPC was initially developed by Sun for the NFS file system. The use of RPC allows calling remote functions as if they were local; programmers don't have to worry about opening connections or converting data, the RPC system takes care of this. If we want to communicate two applications using RPC, we first have to define the functions and data types to be interchanged by client and server using for this a special language. CORBAAs object oriented technologies became popular, they were also ported to the IPC world. CORBA, which stands for Common Object Request Broker Architecture, is an IPC standard based on the OO paradigm. In fact, this approach is very similar to the use of RPCs, because like in this, we call a function with certain parameters. Unlike RPC, remote objects may be created which encapsulate their own data, those objects are manipulated via method calls. The object's data resides also remotely and doesn't have to be send over the network, saving network bandwidth and avoiding type conversion overheads. We can think of CORBA like a next generation RPC, just extended to support object-oriented programming. 

The CORBA architecture is depicted on the following image. The most important component is the ORB (Object Request Broker), which is responsible for all communications for identifying and locating objects, data transmission and for clients calling the object implementations. The object interface is defined by using a special language called IDL (Interface Definition Language). IDL is used for declaring the object interface, not its implementation. It constitutes the contract between client and server. The IDL is then used for generating the stubs for implementing the client and the server skeleton. The implementation language of client and server may differ and depends on the ORB in use. 

A client communicates with the object by using the stub which links it with the ORB. The communication between the object and the ORB is done via an entity called the Object Adapter (OA). The OA essentially handles activating and deactivating object and method invocations.

Clients and objects may also communicate dynamically on runtime without having to use stubs. The Dynamic Invocation Interface (DII) allows a client to issue requests to objects whose interface was unknown on compilation time. An interface repository is used to store object interfaces which can be looked up when required. A Dynamic Skeleton Interface is also available in case the OA doesn't know an object in compilation time.

More information on CORBA may be found under 

MICO and ORBITThe main component of CORBA is the ORB as we just have seen. There are many free ORB implementations, but most of them are not powerful enough or haven't reached yet maturity. For KDE v1, MICO () was chosen as the ORB. The GNOME developers started using MICO, but due to efficiency reasons they decided to write their own ORB, which they call ORBit. MICO has been implemented in C++, while as ORBit was written using C. ORBit claims to be one of the fastest ORB implementations.

Note: recently, version 2 of KDE has been announced, in which the usage of CORBA has been discarded for efficiency reasons. The replacement for CORBA and MICO is called DCOP (Desktop COmmunications Protocol) and is based on X11's ICE. More information on DCOP may be found underhttp://developer.kde.org/documentation/library/2.0-api/dcop/HOWTO.html. The rest of this article is going to refer to KDE v1.

CORBA on the desktopsAfter see what is CORBA we are going to analyse how it is used on the desktops. We can define 5 different uses:General IPC mechanismCORBA presents a simple and a elegant solution to interprocess communications. For example, the GNOME panel uses CORBA to communicate with panel applets. In addition, some games also use CORBA as communication protocol to play in a network environment.Exporting an application's APICORBA is used to export the internal motor of the applications to the rest of the system through IDL files. Any CORBA client will be able to use the services provided by this interface. In KDE all KOffice applications export their interface, on the other hand in GNOME we also have some applications doing it, for example, the gmc file manager and the gnumeric spreadsheet. Exporting application API's is vital if we need a component-based system. This way, for example, an application could use gmc to look for and to select a file within a directory structure.ScriptingIn Linux we must often make very common repetitive tasks. Scripting languages, like Perl or Python, allow to automate them. Some KDE and GNOME programs have scripting interfaces, for example killustrator in KDE and gnumeric in GNOME. For example, suppose that every day we need to update a web page with a statistics graph. We could every day read the data from a text file, put it into gnumeric, create a graph using guppi and export the graph to JPG format for the web page. We could make everything through a small program written in Perl. Another example is scripting using KIllustrator. With these few lines:

doc = Document ("", ior) 
if doc.checkForSelection (): 
sel = doc.getSelection () 
x, y = sel[0].getCenter () 
for i in range(10): 
obj = sel[0].duplicateObject () 
j = (i + 1) * 25 
obj.rotateAround (j, x, y + 50) 
obj.applyFillColor (j, j, j) 
obj.applyPenColor (0, 0, 0)

We will get something like this:

Define system servicesWithin GNOME a standard set of interfaces for system services is defined. Services could be created for common tasks like introducing a new user in the machine or sending a mail. Thus, for example, if we want to make a mail client, we do not need to develop all the code, just make a call to the required interface. This mechanism can cause that future applications will be easier to program and to support.Compound documents and graph componentsKOM/OpenParts in KDE and Bonobo in GNOME are the object models that allow the construction of compound documents and the creation of reusable graphical components. A compound document is a document that is formed by parts of diverse origin. For example, in koffice, a kword document can have a table from kspread or a formula from kformula. Instead of creating an application that implements all the necessary characteristics, we need that this application can interact with other applications or components. For example, instead of adding support to a text editor to publish formulas, we could use a component available elsewhere. KOM/OpenParts and Bonobo are inspired by Microsofts OLE2 (the Windows compound document model).Developer's CornerA comparison between KDE and GNOME without writing about desktop programming would be incomplete. Without pretending to write a tutorial, we quickly show that application design is simple and that you can get good results quickly and easily.Desktop ProgrammingA KDE program is a graphic application builded for Qt and making use of KDE libraries. KDE libraries make possible to have a standard look and feel between all the applications and make the programming easier to developers. Besides, KDE libraries add more widgets to Qt Toolkit. The same definition above is valid for GNOME just replacing Qt with GTK+.Basic Programs

KDE application

GNOME application

/********************* khello.h *********************/ #include #include class KHello : public KTMainWindow { Q_OBJECT public: KHello (void); public slots: void slotHello(); void slotClose(); }; /********************* khello.cc *********************/ #include "khello.moc" #include #include KHello::KHello (void) { QPushButton *hello; QPushButton *close; hello = new QPushButton( "Hello", this ); hello->setGeometry(10,30,85,30); hello->show(); connect(hello, SIGNAL(clicked()), this, SLOT(slotHello())); close = new QPushButton( "Close", this ); close-> settGeometry(10,30,85,30); close->show(); connect(close, SIGNAL(clicked()), this, SLOT(slotClose())); } void KHello::slotHello() { KMsgBox::message (this, "Important", "Hello KDE!!!"); } void KHello::slotClose() { kapp->quit(); } /********************* main.cc *********************/ #include "khello.h" int main (int argc, char **argv) { KApplication *app; KHello *hello; app=new KApplication (argc, argv, "Hello KDE"); KHello hello; hello.setGeometry(100,100,200,100); app->setMainWidget( hello ); hello.show(); app->exec(); }

#include static void buttonHello(GtkWidget *button) { GtkWidget *msg; msg= gnome_message_box_new ("Hello GNOME!!!", GNOME_MESSAGE_BOX_GENERIC,NULL); gtk_widget_show(msg); } int main(int argc, char **argv) { GtkWidget *app; GtkWidget *hello; GtkWidget *close; GtkWidget *hbox; gnome_init ("GNOME example", "1.0", argc, argv); app = gnome_app_new ("GNOME example","Hello GNOME"); /* When the program is closed */ gtk_signal_connect (GTK_OBJECT (app), "delete_event", GTK_SIGNAL_FUNC (gtk_main_quit), NULL); hbox = gtk_hbox_new (FALSE,5); gnome_app_set_contents (GNOME_APP (app), hbox); hello = gtk_button_new_with_label("Hello"); gtk_box_pack_start (GTK_BOX(hbox), hello, FALSE, FALSE, 0); gtk_signal_connect (GTK_OBJECT (hello), "clicked", GTK_SIGNAL_FUNC (buttonHello),NULL); close = gtk_button_new_with_label("Close"); gtk_box_pack_start (GTK_BOX(hbox), close, FALSE, FALSE, 0); gtk_signal_connect (GTK_OBJECT (close), "clicked", GTK_SIGNAL_FUNC (gtk_main_quit),NULL); gtk_widget_show_all(app); /* GTK main loop */ gtk_main (); return 0; }

KDE and GNOME applications.

The best way to know how is desktop programming is to see an example. So we are going to analyze a KDE and a GNOME program.

In figure 1 you can see a basic KDE program. This program is developed in C++, like KDE, using object orientation.

In this KDE program we create a KHello class that inherits from KTMainWindow, the basic class of all KDE applications. The program is splitted in three parts, khello.h being the specification class, khello.cc is the implementation class and main.cc is the main program that calls the created class.

Inside the class KHello we must use Q_OBJECT macro which give support for the "signals and slots" object communication mechanism. If we make use of the Q_OBJECT macro we must use a precompiler named moc. Inside the class implementation we must use the moc output file. Once we have created the KHello class we can make use of it as we want.

The KHello class only has a method, its constructor. In our example this constructor just adds two buttons: Hello and Close. Each button has an associated slot, that is to say, a method. The Hello button slot displays a screen message and the Close button slot end the application.

The main part of the program just creates a KHello class, resizes it and executes it.

As we can appreciate, the construction of KDE programs is not complicated, and the object oriented programming helps to have a readable code. In the developers KDE web page you can find an extensive documentation about KDE classes and how to use them.

We are going now to build a similar application with GNOME, using the GTK toolkit and C.

The first difference that can be observed in the program is that we don't create a class, everything is made in the main program (as C is not object oriented).

We must initialise all GNOME programs with the gnome_init function. The basic widget for all GNOME applications is gnomeapp, which is initialised calling the function gnome_app_new. We create our main window in which we will be able to introduce menus, a toolbar and a status bar. The program inserts in the main window two buttons, Hello and Close. The button hello is connected with its corresponding slot that shows a screen message, while Close button finalises the execution.

As we can see, the desktop programming between KDE and GNOME presents a lot of similarities. From the beginning we must have a basic window and them insert in it all the different objects we need. In both toolkits, Qt and GTK+, communication between different objects can be made using the "signals and slots" mechanism.

Adding the application menu and others

KDE menu	GNOME menu
popup = new QPopupMenu(); popup->insertItem("&Hello", this, SLOT(slotHello())); popup->insertItem("E&xit", this, SLOT(slotQuit())); help=kapp->getHelpMenu(TRUE, "Hi World!"); menu = new KMenuBar(this); menu->insertItem("&File", popup); menu->insertItem("&Help", help);	GnomeUIInfo popup[] = { GNOMEUIINFO_ITEM_NONE("_Hello", "", Hello), GNOMEUIINFO_ITEM_NONE("E_xit", "Quit", Quit), GNOMEUIINFO_END }; GnomeUIInfo help[] = { GNOMEUIINFO_ITEM_NONE("_Help", "Get Help", Help), GNOMEUIINGO_END }; GnomeUIInfo menubar[] = { GNOMEUIINFO_SUBTREE("_File",popup), GNOMEUIINFO_SUBTREE("_Help",help), GNOMEUIINFO_END }; gnome_app_create_menus( GNOME_APP(app), menubar);

Once we have constructed the basic skeleton of our application it is very simple to create menus.

In the KDE application, we are creating a menu with two different parts, File and Help. Inside the File menu we have two options, Hello and Exit, that are communicated with their respective slots, slotHello and slotQuit.

GNOME also provides simple mechanisms for menu creation. In GNOME we have two different ways to create menus, one is directly, in a similar way we made before for KDE, but really more difficult. The other way is filling up a structure and calling to gnome_app_create_menus function (see above).

Creation of toolbar, status bars, support for Drag and Drop protocol, Session Management protocol are aspects quite easy to program.

Considering the great amount of facilities that are provided by the desktops is easy to understand the quick evolution of front-ends for the most important X applications. For example we have gtkdiff, an front-end for the well-known diff application, Word Inspector, a GNOME front-end for the dict program, Kgdb, a KDE front-end for the debugging program, etc.

Now we start to have very good RAD applications (RAD= Rapid Application Design). With this development tools build graphic user interfaces is really easy. In GNOME we have glade, in KDE we have KDevelop. But they are different, KDevelop is really a complete IDE (Integrated Design Environment), while glade is only a graphic interface builder.

 
Glade: GNOME interface builder

 
KDevelop: the KDE IDE

KDE programming APIsBut we need more that the programming examples we have seen before. If we want to have a complete idea about the power of KDE libraries we must speak about the KDE programming API.

The kdecore library contains several classes that are helpful for creating applications. The main classes of this library are:

• KAccel: it handles the hotkeys.
• KApplication: controls and provides information to all KDE applications.
• KConfig and KSimpleConfig: Allow to save and load the application configuration.
• KDNDDropZone: Provides support for Drag inside the Drag and Drop Protocol.
• KDNDWidget: Provides support for Drop inside the Drag and Drop Protocol.
• KLocale: Supports translations and specific formats like dates, numbers, currency and time.
• KProcess: Allows KDE applications to execute child processes in a simple and powerful form. In addition it provides support for communications with the child processes.
• KSocket: Simple way to handle TCP/IP sockets.
• KURL: Handle all type of URL.

The kdeui library gives support to most of the graphical elements inside the applications. Some elements are:

• KToolBar, KMenuBar and KStatusBar provide an easy and flexible way for writing KDE applications.
• Some standard dialogues like for example KColorDialog to select a colour, KIconLoader to select an icon, KFontDialog to select a letter type.
• Some extra widgets like KPanner to create two redimensionable windows or KTreeList to administer tree structures.

There are also some other important extra libraries:

• kfm: allows any application to download internet files by just providing its URL, completely transparent to the user.
• kfile: Supports all the different dialogues for file selection.
• khtml: Library that implements all the necessary widgets for HTML editing.
• kab: Defines the API to access user data bases created with KDE address Book.

GNOME programming APIslibgnome is the utilities library of GNOME. It does not depend on the GTK+ toolkit, so any application may use this library. The main classes are:

• gnome-config: easy way to store configuration files.
• gnome-exec: program execution from GNOME applications.
• gnome-util: diverse utilities, for GNOME and C programming.
• gnome-mime: routines for find the MIME format of a given file.
• gnome-metadata: allows to store information with the file name.
• gnome-i18n: configuration options for internationalisation and localisation.
• gnome-regexp: processing of regular expressions.
• gnome-popt: parser for command line arguments.
• gnome-sound: routines for sound handling.
• gnome-fileconvert: routines for file format conversion.

libgnomeui is the most used library in the programs, it includes the basic elements of user interface and other aspects relative to GTK+ and X as Session Management and a great amount of extra widgets. The main classes are:

• gnome-app: Creates the main window and allows add easily menu bar, state bar and tool bar.
• gnome-app-helper: Simplifies the menu and tool bar creation.
• gnome-stock: Provides to applications defect icons, such a way that you can keep a standard look and feel.
• gnome-dialog: Allows to create our own dialogues.
• gnome-*entry: Allows text entry.
• gnome-pixmap: widget to visualise and to load images.
• gnome-client: Routines for handling GNOME Session Management.
• gnome-mdi: Allows applications to handle multiple documents simultaneously.
• gnome-canvas: A motor to represent structured graphs.
• gnome-dns: Interface for name resolution.

Other additional libraries:

• libgnorba: Routines relatives to the basic use of CORBA in GNOME applications and GOAD (GNOME Object Adaptor Directory), that keeps all object implementations in the system and allows to activate them.
• libart: handles all GNOME drawing characteristics.

Support for Drag and Drop and file selection dialogs are supported by GTK+, not by GNOME libraries.How to install KDE and GNOMECurrently neither KDE nor GNOME are officially supported at CERN. GNOME is available on ASIS () for Linux (RedHat 6.1), Solaris 2.6/7 and partially for other platforms like HP, AIX, SGI and Alpha.GNOMEAs administrator, launch "tkwsm" by running "/afs/cern.ch/asis/adm/bin/asis-wrapper tkwsm". Open the configuration menu and select: 'Family=GNU.DESK, Product=, State=Latest, Access=Default', and then press the 'Add' button. Finish by clicking on the 'Save' button. In the main window click on the Execution button. A Window named ASISwsm will be open. Click on the 'Run now for all' button (this may take a few minutes, depending on your workstation).

For launching a GNOME session, you have to run /usr/local/bin/gnome-session instead of your window manager. You can do that by either creating an executable .xsession file in your home directory:

#!/bin/sh 
/usr/local/bin/gnome-session

Or also by changing your HEPiX configuration, by editing the ~/.hepix/xprofile file to include this line:

HX_WM="/usr/local/bin/gnome-session"

KDECurrently on ASIS, there's no updated KDE version available. On RedHat Linux systems the pre-packaged RPM's are available on AFS.

For RH61, the packages may be found under /afs/cern.ch/project/linux/redhat/cern/6.1/RedHat/RPMS. For the base installation you will need to install:

qt1x-1.44-4 
kdesupport-1.1.2-3 
kdelibs-1.1.2-9 
kdebase-1.1.2-10 
kdebase-lowcolor-icons-1.1.2-10 

With this RPM's, the base functionality is available. Optional applications and components are found in:

kdeadmin-1.1.2-3 
kdegraphics-1.1.2-2 
kdemultimedia-1.1.2-3 
kdenetwork-1.1.2-4 
kdegames-1.1.2-2 
kdetoys-1.1.2-2

As with GNOME, you may either create a .xsession file or modifying your HEPiX configuration for starting up KDE:

~/.xsession

#!/bin/sh 
/usr/bin/startkde

Or adding to ~/.hepix/xprofile

HX_WM="/usr/bin/startkde"

ConclusionDuring these articles we have tried to provide a general overview on both desktop systems, and also to have a look behind the scenes regarding the used technology. KDE and GNOME do share many common points but do also differ on several aspects, as we have seen. We are not going to make any recommendation yet on which system to use but want to invite you, the users, to install the desktops and work with them and provide us with your experience. We are also looking for KDE maintainers who could compile and configure the KDE environment for Linux and other platforms. Any help and feedback is welcome, please contact  or directly . 

More information under