This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern/ for current CERN information.
|
ContentsEditorial If you need help Announcements Physics Computing Desktop Computing
|
X11 Desktop Environments (KDE and GNOME - Part III)Victor Robles, Germán Cancio , IT/PDP AbstractThis 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 (http://www.mico.org ) 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 under
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)
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
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.
Adding the application menu and others
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.
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:
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:
How to install KDE and GNOMECurrently neither KDE nor GNOME are officially supported at CERN. GNOME is available on ASIS (http://wwwinfo.cern.ch/pdp/ose/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=<All>, 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
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
With this RPM's, the base functionality is available. Optional applications and components are found in: kdeadmin-1.1.2-3
As with GNOME, you may either create a .xsession file or modifying your HEPiX configuration for starting up KDE: ~/.xsession
#!/bin/sh
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 contactAsis.Support@cern.ch or directly Germán Cancio
(German.Cancio@cern.ch ).
More information under http://wwwinfo.cern.ch/pdp/ose/gnome_kde/
|