Chapter 13. DCOP—Desktop Communication Protocol

by Cristian Tibirna

One major reason for the rampant dependence upon computers is their capability to greatly simplify the work and life of users. This capability is largely a consequence of the computers' "education"; that is, their programs. The educators (that happy bunch we love to call the hackers) discovered that sociology applies to computer programs as well as people. In order to behave as worthy citizens of a computer, the programs need to know how to communicate.

A long time ago, the UNIX fathers noticed the hunger of programs for communication. Therefore, they invented the genial pipes. Arguably, most of the force of UNIX comes from offering its users the ability to build combinations of small tools. These combinations can reach a potentially infinite complexity. These "metatools" help the user easily accomplish complex tasks. Pipes are an essential ingredient in these combinations. You have probably used, at least once, commands such as

   1 
   2 ]~> find . -name "*.cc" | xargs wc -l
   3 
   4 ]~> cat /etc/passwd | awk -F: 'print $4' > /tmp/users-realnames
   5 
   6 ]~> echo "What a happy world!" | mail -s "Oh yeah!" buddy@paradise.org
   7

Today, we want to develop programs with nicer faces and better capabilities, and we rediscover that communication between applications is essential. Yet, in the time of graphical interfaces, point and click, and what you see is what you get, it is less convenient to use traditional pipes. More advanced communication means are needed.

Thus appeared DCOP, the Desktop Communication Protocol. This name designates the set of tools that KDE programs use to pass information between them.

This chapter describes the programming interface that DCOP defines and gives a few directions and examples.

13.1. Motivation

The K Desktop Environment was designed from the very beginning as a collection of programs, each targeted at resolving a strictly delimited category of tasks. However, the main goal of a desktop environment is to offer the user a unified way of functioning that preserves or even enhances his productivity in a heuristic way, despite the diversity of tasks the user has to accomplish. The validity of this goal is proven by the wealth of integration tools that proliferated around and inside the traditional UNIX window managers (from the times that preceded KDE).

Those window managers had scripting support and other kinds of programming interfaces. They offered hooks for programs willing to take advantage of the specific windowing information accessible to the window manager or to implement integration with the underlying operating system. There also were connections through which programs could manipulate the window manager.

It was not unusual for most window managers to come bundled with helper tools such as task lists, icon managers, or event handlers that took advantage of special communication functions in order to offer a better experience to the user of the graphical interface.

In running KDE, the need for communication between applications stands out. Here are a few examples of interprocess communication needs:

The desktop has to offer feedback about applications' startup dynamics.
Today's applications will often need to point the desktop browser to a URL or offer means for composing mail using the desktop's default mailer agent.
Applications need to be informed about changes operated by the user in the external configuration modules hosted by KDE's Control Center.
Users require a unified interface to the online help offered by applications.
The window manager (KWin) informs the panel (Kicker) about changes in the collection of managed windows.
Part of the changes occurring in a window's status are propagated by the window manager to the event notifier (KNotifier) for proper notification of the user. Also, the centralized notification resources are helpful for all applications, not only for the window manager.
The panel can manage special applications (panel applets) and needs to exchange with them the bits of information related to their status and activities, such as adding and removing applets, required geometry, special menu items to be added to the main menu of the panel, and so on.
Last, but not least, generic desktop control through scripting is in high demand.

Communication is essential even between distinct instances of the same application. Starting with version 2.0 of KDE, the concept of unique application is available. This concept, very simple in essence, stipulates that an application can choose to never have more that one fully running instance. A user can try, of course, to spawn a second instance. It is up to this new process to discover if previous copies are already running. If an older instance exists, the new one should be capable of communicating with its predecessor. Through communication, it would be able to trigger the display of an information dialog box or to pass over the parameters provided by the user, such as the name of a file to open or a special command-line option.

When a given number of applications are in charge of similar tasks—for example, the processing of users' mail—collaboration between such applications is very useful. Imagine, for example, a tiny mail monitor that sits in the background and checks for new messages in multiple mailboxes. In the event of a new incoming message, the monitor should be able to send event information to the system's notification handler (KNotify), check whether there is any running mail agent, and if there is, try to communicate to the mail agent information that will promptly modify its status.

As you can see, building reliable means of communication in the backbone of KDE is necessary. Doing this in such a way that the resulting programming interface is simple, easy to use, and efficient is also highly important. DCOP offers all these and more.