# Chapter 9-

Using Many Applications Together - `Inter-Client Communications'

#### Introduction

In the last chapter we saw how a window manager and a single cfient operate together. Here we move on to look at the mechanisms any applications can use to communicate with each other, and how multiple clients interwork with one another. We cover the issues involved in making very different clients - perhaps running on different operaung systems and networks - interwork together; of necessity this is quite complex, and if technical details are not so relevant to you, you can skip over ttus chapter.

## 9.1 Why applications need to communicate with each other

User applications interact with one another to provide cut-and-paste facilities, and to exchange data within a suite of related applications. X user applications also have to communicate with the window manager, to indicate preferred size, position, etc. The X server must provide communication mechanisms because clients may not be able to communicate directly.

X is a multitasking environment, so you can expect to have many different applications working onscreen simultaneously. To get the maximum benefit from multiple applications you must be able to exchange information between them. We can divide the information which needs to be exchanged into three broad classes:

1. Information that the user explicitly transfers. When you are using several programs for different parts of some overall task, you often want to move information around. For example, if you are sending an electronic mail message concerning some budget information, you might query an accounting application, transfer the result into a spreadsheet program, use a calculator on some of the spreadsheet data, and finally incorporate the results into your mail message.

   The most common way to move information explicitly is to cut-and-paste. You specify which data you want to transfer (usually by clicking or dragging with the mouse within one application) and then include it in the other application either by mouse clicking or by selecting a special paste menu option. In Modules 9.2.1 and 9.4 we'll see two different mechanisms X provides for cut-and-paste.

2. Information transferred automatically by the applications themselves. Some applications operate together automatically. For example, a `talk' application which enables one user to have an interactive dialogue with another running a similar application will require automatic transfer between the two programs of the text each user types in.

   Other suites of programs may be divided up functionally, so that one program in the suite manages the data, another is the front end used to interact with or control the system, and one or more other programs display views of the current state of the system. In these cases the applications would initiate their own communications with each other.

   Some X-specific applications such as user interface builders and rapid development tools also need to send information to each other. As a simple example, the standard MIT program editres (see Module 12.5) allows you to interactively edit various settings of the widgets in a running Toolkit program. editres runs as a separate program, but it sends messages to the application you are editing, and also receives information from it.

3. Information transferred for system functions. We have already seen that user applications and the window manager need to communicate with each other. Other system-like functions requiring communications facilities are desktop managers, discussed in Module 9.6.

The window system itself - the server - must provide the mechanisms for applications to communicate with each other, and all communication between the applications must be via the server. This is essential because the applications may not be able to talk to each other direc;tly; as shown in Figure A, the applications may be on different networks or using different protocols on the same network.

In the rest of this chapter we look at the general mechanisms X provides which are used for clients to communicate with each other, in particular properties and send events. We then go on to see how higher-level communications services, in particular the X selections mechanism, can be built using these, and look at the standards laid down for these functions. Finally we look briefiy at some desktop managers, which require these features.

###### Figure A. Applications may not be able to communicate directly, so information is sent via the server.

## 9.2 `Properties' - the basic mechanism for inter-client communications

An application can store arbitrary data in named locations called `properties' on the server, and other applications can retrieve the data from there. This simple mechanism is used for almost all communication between applications, and it can be used to construct sophisticated inter-client communication protocols.

X's properties provide the basic mechanism for most communication between applications. The idea of a property is that it is a named piece of (arbitrary) data related to (or attached to) a particular window. An application stores information in a property, using the Xlib function XChangeProperty(). After that, any other application which knows the name of the property (and the window it's related to) can retrieve that information, using the Xlib function XGetProperty().

Several windows each can have a property of the same name, but because each of these properties relates to a different window, each of these properties is distinct, can contain different data, and can be accessed separately. This fact is commonly used: for example, each application window typically has its own group of properties (WM_CLASS, WM_NAME, etc.) containing information needed by the window manager to handle that particular application.

Any application can access and modify the contents of a property - not just the one that created or first wrote data into it. Also, the property lives on even after the client that created it has terminated. So properties really are truly shared resources.

Retrieving the value of a property involves a round-trip: the client sends the request asking for the value, and the server sends the value back as a reply.

The typical use of properties combines all the above features. Applications which need to exchange information with each other agree on (or have hard-coded into them) the name of a property which they will use to pass the information, and to which window the property will be attached. Again, applications passing information to the window manager are a good example of this: both applications and window manager know that the property names are WM_CLASS, WM_NAME, etc., and that they are attached to the application's main or top level window. Figure A shows the properties on an OPEN LOOK menu, listed using the MIT program xprop.

In the next module we look at some examples of how properties are used in an X system.

###### Figure A. Listing prOpertieS on a window with xprop

### 9.2.1 Examples of the use of properties

Properties are used widely, for communicating default values to applications, and to allow cut-and-paste between applications.

A simple example of the use of properties is the standard MIT program xrdb. This stores default settings for programs in a special property, RESOURCE_MANAGER, on the root window. Each application as it starts up looks for this property, and if the property exits, the application reads the default settings from the property rather than from a file, as illustrated in Figure A. The settings in the file myresf are usually loaded into the RESOURCE_MANAGER property with the MIT program xrdb as soon as the server has started, and the value is then checked by listing all the properties on the root window with the xprop command, as shown in Figure B.

Settings have to be stored in a property rather than a file, so that all applications using the particular display can access these settings; if they were stored in a file on one particular machine, they might not be accessible to applications on other machines which may be on a different network or using different network protocols or different operating systems. The root window is used beeause it's always present once the system has started, so every application can always access it.

#### Example - cut-and-paste of text using cut-buffer properties

Another example of the use of properties is cut-and-paste using cut buffers. When you `cut' some text, that is, select it, the application you used to select that text copies it into a property called CUT_BUFFER0 on the root window. (Again, the root window is used because it's always present and accessible to every application.) To help the user, applications typically highlight or show in reverse video the text that has been selected.

When the same or another application wants to `paste' the previously selected text, it just retrieves the data from CUT_BUFFER0 on the root window. The information is cut and pasted as a stream of text characters or bytes.

Figure C shows some text selected in an xterm window, with the corresponding value of the CUT_BUFFER0 property shown beside it.

While these cut buffers are still available in the standard MIT release of X, they are historical, and should not be used by newly developed applications. 'The Selections Service (Module 9.4) should be used instead.

In the following modules we look at the more sophisticated mechanisms for handling properties and see how they can be used to build more elaborate communications, for dynamic data interchange.

###### Figure A. xrdb stores values into the RESOURCE_MANAGER property.

###### Figure B. You load properties into the RESOURCE_MANAGER property with xrdb, and check them with xprop.

###### Figure C. Selected text is highlighted, and stored in the CUT_BUFFER0 property

## 9.3 Advanced communications mechanisms

When a property is changed, the server generates a PropertyNotify event, so that applications can be informed immediately of the change; this allows efficient dynamic communication between applications. Properties contain `typed' information, so complex data can be exchanged among cooperating applications.

(If technical details aren't so relevant to you, you can skip over this module.)

#### Advanced property mechanisms

The first mechanism relates to how an application finds out when the value of a property it is interested in has changed. For simple exchange of information driven by the user as with cut-and-paste, just looking at the property when its value is required is both adequate and efficient. However, where the transfer of information must be dynamic something better is needed and X does provide it: when a property is changed by an application, the server generates a <PropertyNotify> event. Applications which need intimate communication select for <PropertyNotify> events on some mutually agreed window, and thus they are more or less automatically notified when the property they are interested in changes. (In fact, they are told when any property on that window changes, so the applications do have to check which property it was that changed.) Then they can perform any actions required by the change. This mechanism is analogous to an operating system handling VO in an intenupt-driven way, as opposed to polling the hardware periodically to see if any change has occurred.

The second feature of properties is that they are typed, so they can contain information in the representation most convenient for the applications that are using it.

- Many standard types are pre-defined. For example, CUT_BUFFER properties are of type STRING as they are used to contain text. Other built-in types include INTEGER to contain numbers, WINDOW to contain a window identifier, WM_HINTS and WM_SIZEHINTS to contain the information passed between application and window manager, and many others.
- You can define your own property types, as complex as you wish, in much the same way that in a language like C you can construct arbitrarily complex data structures from the fundamental data types (using typedef 5truct). Thus, for example, you could have your own data type for interchanging `objects' if you are building an object-oriented user interface. Or in an office automation suite, you might define a property type to hold all the information about a customer, and this property would be used to pass customer details in a standard format to the various applications --- database, electronic mail, word processing, fax, etc. Then each application would incorporate the information it required, for example the fax program would use the customer's fax number, name and organization, but would ignore the postal address details.

### 9.3.1 Sending events from one client to another

Applications can construct `synthetic' events and send them to each other via the server, providing another level of inter-client communication. Any type of event can be sent, but `ClientMessage' events are provided specifically for applications to exchange information.

The final mechanism for applications to communicate is for one application to request the server to send an event to the other. The exact details of the event to be sent are specified in the request. The other applieation processes this event when it receives it (Figure A).

#### ClientMessage events

One type of event, <ClientMessage>, is provided specifically for clients to pass information to other clients. These events have a slot of 20 bytes which can be used for any information whatever to be sent to another application. (If you want to send more than 20 bytes, you have to send several events.) For example a talk program has been implemented which transmits all the text of a dialogue between two users via events sent from one running copy of the program to the other. The editre5 program of Module 12.5 uses <ClientMessage> events to communicate with the application you are editing; these events are processed by X Toolkit code within the application, interrogating or changing parameters of the widgets in the application. Window managers also use <ClientMessage> events, to send messages to applications requesting them to perform the WM_PROTOCOLS actions we described in Module 8.4.1 (and for some other obscure purposes relating to reconfiguration of application windows).

#### Sending other types of event

<ClientMessage> events are not the only type of event one client can send to another --- any event-type can be sent. The receiving application receives the event exactly as though it had come directly from the server, with the exception that a status indicator in the event is set ON to say this is a send-event. The most common example of this is the way some window managers (including twm) process keyboard input that is typed in an application's icon or window decorations. The server sends these events to the window because it is the owner of the window where the input took place; the window manager then passes these events on, as send-events, to the corresponding application window.

However, send-events can be a security hole; by sending <KeyPresS> events to the application you are running, an intruder can effectively type anything into your application, bypassing all your password and other security mechanisms. For this reason, applications should allow you to specify that send-events are to be ignored. (For example, the MIT program xterm has an option controlling send-event processing, so you can specify in a defaults file that it is to be disabled; it also has a menu selection, shown in Figure B, allowing you to interactively enable or disable the send-event processing.) Send-events can be very useful in testing a system. If you can capture all events

when you are running the system interactively (and there are facilities to let you do this - see Module 13.4.1) then you can later `replay' the events to run the system automatically just by re-sending all the events which were recorded, either by having a special application, or by a special modification to the server to allow this.

Finally, send-events are used extensively by the Selections Service covered in the next module.

###### Figure A. One client can cause an event to be sent to another elient

###### Figure B. xterm menu lets you enable or disable send-event processing.

## 9.4 The Selections Service - a high-level communications mechanism

The Selections Service uses properties and send-events to pass data between applications. The applications can negotiate dynamically about the format the data is to be sent in. The mechanism is extensible - sets of applications can define their own private and sophisticated conventions for exchanging data between themselves.

(If technical details aren't so relevant to you, you can skip over this module.)

Like a property, a selection is a name on a server. However, unlike a property it doesn't have any data attached to it, and it is not related to a particular window. Instead, the selection is a place-holder for information that ean be obtained from somewhere else.

X defines three standard selection names, PRIMARY, SECONDARY, and CLIPBOARD, which are used by the Selections Service. X provides for ownership of selections. Only one client at a time owns a selection, and then any other client can find out who the owner is. Having found out, the second client can ask the owner for the value the owner associates with the selection. Any client can request ownership of any selection when it wants to make some data available. Thus a selection just acts as a type of flag - an abstract token which allows `ownership' to be shared and controlled amongst the different applications, as we describe below.

The most common example of selections is the use by all (up-to-date) clients of the PRIMARY selection as the principal means of exchanging information, typically as a cut-and-paste mechanism. The SECONDARY selection is intended for tasks which require two pieces of information --- for example, `swap this selection with that one'.

The fundamental diffetence between this use of selections and the cut buffer mechanism we described in Module 9.2.1 is that no information is transferred when ownership is asserted (that is, when you `cut' or select some information in an application). Instead, the transfer of information is deferred until another application requests the information from the selection owner. This allows the owner to send different data, or the same data in diffenent formats, depending on the requesting client and what it needs to receive; this decision by the owner about what to send is made each time the selection is requested.

Why is it necessary or useful to delay passing the information until it has actually been requested? Let's consider `cutting' a portion from a spreadsheet, and pasting it to another application: what information should be transferred? Should a bitmap of the spreadsheet, with all its graphics, multiple fonts, etc. be transferred, or just the ASCII characters representing the values in the selected spneadsheet cells? Or should it be the spreadsheet's internal representation of the data? It is impossible to give a single `correct' answer; what should be transferred depends on the particular pair of clients involved. And even for the same two clients, different formats may be required at different times: if I am using a DTP system to prepare a manual for the spreadsheet program, when I paste the information I'll probably want an exact graphic representation of the screen image, whereas if I am using the spreadsheet to generate information to be included in a report I am writing with the DTP system, I may only want the spreadsheet information as columns of ASCII characters. By waiting until another application requests the value of the selection, the owner can at the time of transfer decide what information and which format is to be used. By contrast, with a cut buffer, once the `cut' has been performed the information has been stored, and the `owner' no longer has any control over it. Figure A shows schematically how the same selection is transferred in very different formats depending on which application requested the value; the next module discusses in detail the precise mechanisms involved when the Selections Service is used.

###### Figure A. The owner can transfer different representations of the same selection to different requestors.

### 9.4.1 The detailed data transfer mechanism using Selections

An application requesting the value of a selection can specify the format it wants the data in, by specifying the type of the property to be used to receive the data. Therefore the data format, and even which data is sent, can be decided dynamically for each transfer requested.

(If technical details aren't so relevant to you, you can skip over this module.)

The process used to transfer information using selections is quite long-winded. Figure A shows the steps for cutting (or selecting) information in application A, and pasting it into application B, and then later into application C.

This illustrates how events are used to inform the owner that some other application requires the value of the selection, and in turn to tell that requestor who the owner is. It also shows that all the data transferred goes via properties, and therefore via the server.

Note that the process is dynamic and active rather than passive: the owner converts the data and transfers it explicitly each time the selection is requested, even if it is the same information and the same format as before. Different values and formats can be transferred even when the selection as seen by the user remains the same. In the previous module we gave an example of pasting from a spreadsheet. Another example is a window manager where clicking on a window adds that window to a list accessed via the PRIMARY selection. If you `paste' this selection, it is converted to a list of names of the windows as text; but if you perform a move operation, the selection is converted to a set of window identifiers, and then each window is moved in the way you specified, so that the overall effect is that the windows are moved as a group.

###### Figure A. Transferring data using selections.

### 9.4.2 Selection clipboards, and Selection data formats

If the owner of a selection terminates, other applications can no longer obtain the value of the selection; a `clipboard client' can overcome this problem, but the dynamic nature of the selection transfer is lost. Applications can define their own selections as well as the format to be used for selections, and can even ask the owner of the selection which data formats it can support. Large data transfers via selections are handled in many pieces.

A side-effect of the dynamic nature of the transfer is that if the application which is the owner of the selection terminates for any reason, other clients can't paste the information any more - it isn't held in an (intermediate) clipboard. (You can see this for yourself if you run the standard MIT program xfontsel, press its Select button, and paste the value into another application. Then quit from xfontsel, and paste again: you don't get the same value any more, as xfontsel is no longer the owner of the selection.)

This drawback can be overcome to some extent by using a special `clipboard client' program, which continually monitors the CLIPBOARD selection. As soon as it changes, the special client requests the value of the selection from the owner, and then takes ownership of the selection itself. The value of the selection the clipboard client will supply to any requestor is the same information as it retrieved. Now if the initial owner of the selection terminates, the clipboard client still retains the information. (The MIT release contains the MIT program xclipboard which works in this way; relatively few MIT applications use the CLIPBOARD selection by default, but Motif and OPEN LOOK use it for copy/cutlpaste operations.) The advantages of this scheme are the stability it gives, and that the special client can constantly display the contents of clipboard as an aid to the user. However, the disadvantage is that we have lost flexibility; by converting the data `early'- as soon as it is selected - we have lost the dynamic and adaptive behaviour which is the main benefit of selections.

#### Selection format

Data is transferred by storing it in a property, from which it is then read; the format of the data is determined by the type of the property. All the standard property types can of course be used, but as we mentioned in Module 9.3, applications can define their own property types, and so arbitrarily complex typed information can be exchanged using selections. A requestor can even ask the selection owner for a list of the formats it supports, and then choose the format it likes best for the owner to use for the actual data transfer.

Obviously, the amount of data you can store on a property on a window is limited --- by the amount of memory available in your server if by nothing else. If a very large amount of information has to be transferred, the Selections Service includes a mechanism whereby the information is passed in successive small chunks, so that the server isn't swamped.

As well as defining your own data formats, you can also define your own selections (that is, create new selection names) which you might use in a suite of applications which need to communicate among themselves. (However, all selections are publicif an application knows the name of a selection it can access it, and there is no way to restrict this access.) For example, specific selections like this are used to communicate between the various processes involved in some of the more complex input methods for Oriental languages.

The standard X Toolkit contains a lot of code to handle selections and simplifies their use. Even so, programming selections correctly is quite complex, and many earlier X programs don't use them but rely on the historical CUT_BUFFER mechanism.

## 9.5 ICCCM - the rulebook for inter-client communications

The `Inter-Client Communications Conventions Manual' (ICCCM) specifies conventions for client/window manager and client/client interactions. These conventions are necessary to ensure that applications and window managers from different developers can co-exist on the same system, and inter-operate correctly.

(If technical details aren't so relevant to you, you can skip over this module.)

The ICCCM lays down the rules for how clients - both user applications and the window manager - communicate with each other. Of necessity it is complex and obscure, because it is specifying general mechanisms for how clients cooperate, but as far as possible without artificially limiting what can be done. In a way one might think that the ICCCM is breaking the X ideal of `mechanism not policy', but if the user is to be able to operate applications and window managers from very diverse sources satisfactorily, then some rules must be laid down.

Fortunately, only programmers need concern themselves with the ICCCM, and even then the standard toolkits help a lot, and do most of the work. (In itself, this is a very good reason to use a toolkit.)

An outline of the ICCCM table of contents is shown in Figure A. The parts of most interest to us are Section 2, dealing with Selections, and Section 4, dealing with the interacting of window manager and client. In fact we have already covered Section 2, as the mechanism we outlined in the previous module for data interchange using the Selections Service was exactly as specified by the ICCCM.

How window manager and application interact is probably the most frequently quoted pan of the ICCCM. It gathers together many of the aspects of window management that we have already mentioned so far, including:

- The requirements that applications should be independent of window manager policy (Module 8.3) and that the application should accept the window configuration the window manager has given it (Module 8.4.1).
- The properties WM_HINTS, WM_INFORMATION, WM_ICON_NAME, etc., which we covered in Module 8.4.1, and how they should used by the application when it stans, to indicate its preferred size, layout, etc.
- The WM_PROTOCOLS mechanism for specifying which publicly or privately defined messages or function-requests the application will obey if the window manager sends them (WM_SAVE_YOURSELF, etc., described in Module 8.4.1 ).
- Focus handling (Module 8.1).
- Handling colormaps (Module 8.1 ).

Other window manager-related ICCCM topics are:

- How pop-up windows are to be managed. They must be handled specially - imagine how awkward it would be if every time you popped up a menu you got a rubber-band outline, and had to use the mouse to position the menu before you used it!
- Managing icons.
- Managing groups of windows as a single unit, although this is currently not handled by many window managers.

Prior to Release 4, most window managers did not comply with all the ICCCM rules, especially in the area of colormap management. Since then, most widely-used window managers have been brought into line. The ICCCM continues to evolve, both as experience shows that its scope must be extended, and as new requirements develop. For example, colour management was included with Release 5, and in future we can expect sections covering `drag and drop', session management, and anything else which relates to how a set of applieations can cooperate closely to produce a more unified environment.

###### Figure A. Topics addressed by the ICCCM.