Perhaps that the most exciting thing about the DCOP technology is the amazingly effective way in which its use speeds up the KDE development by many orders of magnitude. The team of KDE developers made insistent attempts to use a traditional CORBA implementation as a technological basis for the accomplishment of a project's interprocess communication needs. It is now generally accepted that this was a conceptual error. One of the central reasons of this humble acceptance is exactly the outcome of the greatly successful DCOP/KParts experiment. DCOP was introduced in general use in KDE's development only days after its inception. This was possible thanks to its brilliant technological simplicity and to the sound conceptual principles employed. The authors acknowledged to have been surprised by the extent to which the members of the development team currently use DCOP in all categories of KDE code. Following are a few examples of such usage. One visibly weak point of the KDE 1 API was the lack of an easy-to-use programming technique that would have allowed the creation of unique applications. The term unique applications designates a special category of programs that don't need to—or must not—exist in more than one running instance at a time in a distinct active desktop environment session. This problem is solved in the current iteration of KDE. A special class named KUniqueApplication exists now. This inherits the central KApplication class. The unique application concept defines special requirements: Detecting whether previously running instances of the same application exists. Communication with the previously running instance. Limited control of the previously running instance.
These are all achieved by proper use of the DCOP technology. A simplified description of the way a KUniqueApplication functions follows: At construction, a DCOP client is automatically created and then attached to the DCOP server. The current instance of the application tries to detect whether a previously running instance of itself exists: If no previous instance exists, a proper registration with DCOP server is automatically performed and the application proceeds with its normal functioning. If a previous instance exists, command-line parameters (and eventually programmed messages) are passed to a special method of the object and then this instance immediately quits.
Typical usage of this class is simple. There are two aspects that require attention. First, the existence of a previously running instance is checked by the use of the KUniqueApplication::start() method, which is statically defined. It is recommended that you take advantage of the static definition of this method; that is, call it before the proper construction of the main object (of type KUniqueApplication). This way, fewer resources are used during startup if a previous instance already exists. Startup times are reduced by 40% in such a case. These ideas are exemplified in many places in the real KDE 2.0 code base (many applications are built as KUniqueApplications). Listing 13.15 offers such an exemplification as extracted from the International Keyboard application.
Example 13.15. A KUniqueApplication has a Special Way of Starting 1
2 File: kikbd/main.cpp (from real KDE-2.0 base code)
3 --------------------------------------------------
4 .
5 .
6 16: KAboutData about("kikbd", I18N_NOOP("International Keyboard Selector"),
7 17: "2.0", I18N_NOOP("Run time selector for keyboard layout"
8 18: "on the desktop or on individual windows"),
9 19: 0, " 1998-2000 Alexander Budnik, Cristian Tibirna",
10 20: "","http://devel-home.kde.org/~kikbd");
11 21: about.addAuthor("Cristian Tibirna", I18N_NOOP("Current maintainer"),
12 22: "tibirna@kde.org");
13 23: about.addAuthor("Alexander Budnik", I18N_NOOP("Original author"));
14 24: about.addCredit("Dimitrios Bouras", I18N_NOOP("Bug fixing"));
15 25:
16 26: KCmdineArgs::init(argc, argv, &about);
17 27:
18 28: static KCmdLineOptions opts[] =
19 29: {
20 30: {"rotate", "change the keyboard layout programmatically", 0};
21 31: {"reconfig", "read again the configuration,
22 probably on kcmkikbd's demand", 0};
23 32: };
24 33:
25 34: KCmdLineArgs::addCmdLineOptions( opts );
26 35:
27 36: KiKbdApplication::addCmdLineOptions();
28 37: if (!KiKbdApplication::start())
29 38: exit(0);
30 39: KiKbdApplication appl();
31 40: appl.exec();
32 .
33 .
34 |
Second, when you want to pass command-line arguments to a previously running instance of the application, you must reimplement the KUniqueApplication::newInstance() method. The automatically created DCOP client passes the parameters over the desktop communication protocol from the new instance to the previously existing one (the master). The DCOPObject::process() method of the master implicitly calls the special newInstance() method and passes to it a string list containing the said command-line arguments, as exemplified in the Listing 13.16.
Example 13.16. A KuniqueApplication has a Special Way of Passing Command-Line Parameters to Predecessors 1
2 File: kikbd/kikbd.cpp (from real KDE-2.0 base code)
3 --------------------------------------------------
4 .
5 .
6 151: int KiKbdApplication::newInstance () {
7 152:
8 153: kdDebug(1420) << "Parse cmdline args" << endl;
9 154: KCmdLineArgs *params = KCmdLineArgs::parsedArgs();
10 155: if(params->isSet("reconfig")) {
11 156: kdDebug(1420) << "Remotely trigger loadConfig" << endl;
12 157: QTimer::singleShot(configDelay, this, SLOT(askReloadConfig()));
13 158: ::exit(0);
14 159: }
15 160: if(params->isSet("rotate")) {
16 161: kdDebug(1420) << "Remotely trigger rotateKeymap" << endl;
17 162: QTimer::singleShot(configDelay, this, SLOT(askRotateKeyMap()));
18 163: ::exit(0);
19 164: }
20 165:
21 166: params->clear();
22 167:
23 167: //CT if it comes up to here, it's either that the params are wrong or
24 168: // that there weren't params. Either is wrong.
25 169: kdDebug(1420) << "Warn for bad use" << endl;
26 170: KMessageBox::sorry(0,
27 171: i18n("Only one instance of the international keyboard "
28 172: "configuration\ncan run at a given moment."),
29 173: i18n("Already running"));
30 174: ::exit(0);
31 175:
32 176: }
33 .
34 .
35 |
Important components of the typical KDE desktop session are making use of the KUniqueApplication paradigm: KDesktop Kicker (the KDE desktop panel) KMenuEdit (the menu editor used for Kicker) Klipper (KDE's enhanced clipboard manager) KMail
These are all excellent examples for a proper use of the KUniqueApplication technology. | |
Another important improvement brought by KDE 2 code base over what KDE 1 offered is the new system notifications mechanism. In a very simplified presentation, KNotify (the KDE system notifications mechanism) is constituted from a client API and an events server (running on the desktop under the name knotify). Every application that wants to use the system notifications needs simply to import the KNotifyClient namespace provided in the KDE libraries. Configuring events is noticeably easy (a control center module is available). There are a few types of notifications associated with an event: sounds, dialog boxes, and log file entries. The actual contents of these notifications is also configurable. The notifications server remains permanently active on the desktop and is in close relation with KDE's multimedia server (artsd). The communication between clients using the KNotify mechanisms and the notifications server is once again greatly facilitated by DCOP. For an easy understanding of how to implement event notifications in a KDE application, it might be useful to examine the source code of KDE's window manager, kwin (especially the files kwin/events.cpp and kwin/eventsrc). | |
dcop and kdcop are perhaps some of the most surprising examples of powerful usage of the desktop communications protocol. These two little tools were born during the prolific coding session that took place in Trysil, Norway, around the middle of 2000. They are amazingly capable and make use of the latest functionalities added to the DCOP API: the information mining methods (see the section "Stay Informed" earlier in this chapter). These two tools enable the user to browse in real time the composition of the DCOP object pool, and even invoke functions provided in the public DCOP interfaces. dcop, or the DCOP shell client, is a command-line tool. Listing 13.17 is a short session using dcop.
Example 13.17. A Desktop at the Fingertip 1
2 ]:~> dcop —help
3 Usage: dcop [ application [object [function [arg1] [arg2] [arg3] … ] ] ]
4 ]:~> dcop
5 ]:~> dcop kdesktop
6 ]:~> dcop kdesktop KScreensaverIface
7 ]:~> dcop kdesktop KScreensaverIface save
8 |
Enjoy! kdcop is the counterpart of dcop but with a graphical interface. The DCOP objects hierarchy is equally easy to explore or to exploit from kdcop's graphic console (see Figure 13.2). | |
DCOP benefits from an open-minded design that avoids to a large extent the use of specific KDE technologies. Yet, DCOP itself is inherently a KDE technology. Its authors are hoping, though, that DCOP will be equally well adopted outside KDE's code base. Reasons for such hopes are the elegance of the basic principles used, as well as the great convenience and performance gains that DCOP provides. Along these lines, members of the KDE developer team created a fairly large collection of bindings around the DCOP programming interface. dcopc is a fully functional interface to DCOP written in the C language by Simon Hausmann and Rik Hemsley. It is available from the KDE project's code base and is intended for programmers willing to write applications with DCOP enhancements in plain C. This effort was at the time of this writing in a development phase, but very near completion. KXMLRPC is written by Kurt Granroth and is an interfacing solution between DCOP and the popular XML-based remote procedure call technology. XML-RPC gained a lot of attention in the past few years from developers of computing solutions for heterogeneous platforms. The greatest benefit that derives from having a bridge from DCOP to XML-RPC is the flexibility in scripting KDE. Almost all important programming languages of modern times (Python, Java, Perl) are offering an XML-RPC implementation. One of the most interesting successes of binding DCOP with XML-RPC is the gained capability of controlling a KDE desktop remotely, even from a Macintosh computer or from a handheld computer (during the tests, a functional Python implementation was used on the Macintosh as a source of XML-RPC commands). This is made possible by the fact that the described binding mechanism provides a lightweight server for XML-RPC on each KDE desktop—very similar to a simple http server. This server is capable of receiving XML-RPC messages and acts as a DCOP client in the meantime. Proper security and authentication mechanisms are implemented in this server. More details about XML-RPC are available at http://helma.org/lists/listinfo/xmlrpc. DCOP bindings for Python were also developed recently by Torben Weis. They are currently available as a proof of concept but they already show a strong potential. | |
| |
