Selections, cut buffers, and drag-and-drop are the mechanisms used in the X Window System to allow a user to tranfer data from a window to another. Selections and cut buffer are used (typically) when a user selects text or some other data in a window and paste in another one. Drag-and-drop is used when a user selects something in a window, then clicks on the selection and drags it into another window. In computing, the X Window System (commonly X11 or X) is a windowing system for bitmap displays. ...

Since the two windows may be handled by two different applications, these mechanisms require two different clients connected with the same X server to exchange data. The X protocol includes some requests and events that are specific to selection exchange, but the transfer is mainly done using event sending and window properties, which are not specific to selection transfer.

Data to be transferred between clients can be of different types: it is usually text, but can also be a pixmap, a number, a list of objects, etc. In the following, only the case of text is considered.

Selections and drag-and-drop are active mechanisms: after some text has been selected in a window, the client handling the window must actively support a protocol for transferring the data to the application requesting it. On the contrary, cut buffers are a passive mechanism: when the user selects some text, its content is transferred to a cut buffer, where it remains even if the application handling the window terminates and the window is destroyed.

Selection

The X Window System supports an arbitrary number of selections; every selection is identified by a string (more precisely, a Atom). The selection that is mostly used is that named PRIMARY. In what follows, this selection only is considered, but it is clear that everything applies to other selections as well.

The following requests are specific to selection transfer (which however involves other requests as well.)

1. request for which window is the owner of the selection
2. request to set the window that is the owner of the selection
3. request to convert the selection

The owner of the selection is (typically) the window in which the selected text is located, if any. When the user selects some text in a window, the client handling the window is supposed to tell the server that the window is the owner of the selection.

Whenever the user attempts to paste the selection into another window, the handler of this other window initiates a protocol for getting the selected text from the other client. This protocol involves the second and third requests of the list above, but its specification is not given at level of the X protocol but as a convention in the Inter-client communication convention manual. In computing, the Inter-Client Communication Conventions Manual (almost universally referred to by its initials, ICCCM) is a standard for X Window System clients to interoperate on a single server. ...

In particular, the client where the selection has to be pasted begin asking the server which window is the owner of the selection. The selection is then transferred via an exchange between the two clients via the server, involving a property of a window (a property of a window is not a phisical attribute of the window but simply an arbitrary piece of data attached to it).

1. the recepient of the selection request the selection to be converted, specifying a property of a window (this may be the window where the text has to be pasted)
2. in response to this request, the server sends to the current owner of the selection a SelectionRequest event;
3. the owner of the selection places the text that is currently selected in the property of the window that the requestor has specified by sending a ChangeProperty; request to the server
4. the owner of the selection sends the requestor a SelectionNotify to notify that the selection has been tranferred (actually, the owner sends a request to the server for this event to be sent to the requestor)
5. the requestor can now read the selection in the property of the window by sending one or more GetProperty requests to the server;
6. the requestor destroys the property; if the selection owner has requested to be informed of this, it is send a PropertyNotify event.

This is the sequence of steps that take place when the content of the selection is considered sufficiently small to be transferred all at once. If the content is large, it should be transferred in chunks. In this case, both clients express interest in PropertyNotify events: this way, the selection owner knows when the selection has been read, and the requestor knows when another chunk has been placed in the property.

Cut buffers

Data, and in particular the selected text, can also be transferred using cut buffers. These are simply properties of the root window, named CUT_BUFFER1, etc. Contrarily to selections, the cut buffers do not involve a direct interaction between clients. Rather, when text is selected in a window, the window owner copies this text into the property of the root window of name CUT_BUFFER1. When the user pastes the text in another window, the window owner reads this property of the root window. In the X Window System the background or desktop i. ...

Xdnd

Drag-and-drop in the X Window System is regulated by the Xdnd convention. When the user drags the selected text into a window and releases the mouse button, the exchange of data is done as for the primary selection. What makes drag-and-drop complicated is what happens during the drag, not what happens after the drop. Namely, when the user drags the selection in different parts of the screen or of a window, they expect to be able to tell when text can be dropped or not. In particular, the image of the cursor (which the user metaphorically identifies with the dragged text) should change depending on whether the text can be dropped in the current position or not.

In the Xdnd protocol, the window where the text is selected and the drag begins is called the source; the window where the cursor is currently in is called the target. The communication between the source and the target is driven by the source client, which also decides the shape of the cursor. Since this shape is supposed to change depending on whether the text can be dropped in the current position of the target window, an exchange between source and target is necessary.

A client can state that a window can be the target of a drop by creating a property of name XdndAware. This way, all applications that has been written without taking drag-and-drop into consideration at all will be recognized by the lack of this property and ignored by all drag-and-drop sources.

When the cursor enters the target window, the source checks the presence of the XdndAware property on that window. If this property is present, an exchange begins:

• the source tells the target that the cursor has entered the target while dragging some data by sending an event XdndEnter
• the target can find out which kind of data is dragged (text, image, etc.) by looking at this event and possibly by further interaction with the source

When the cursor is inside the target window:

• the source sends XdndPosition events to tell the target where the cursor currently is
• the target replies with XdndStatus events to tell the source whether the data can be dropped in the current position
• the source sends a message XdndLeave or XdndDrop when the cursor has left the window or the button has been released

In case of drop the target requests the selection to the source as usual. When the transfer of the selection is concluded, the target sends an XdndFinish event to tell the source that the transfer has been successful, so that the source can give a visible feedback to the user.

Summarizing, the protocol is driven by the source, which keeps the target informed of what is happening with the cursor. In reply, the target tells the source whether a drop would be accepted or not. The target must also be informed when the user releases the mouse button, as this event starts a regular request for a selection, which is a protocol driven by the target.

The above is the description of the Xdnd convention for drag-and-drop. Different conventions for drag-and-drop are used in Motif, OffiX, and Amulet.

See also

• X Window System protocols and architecture
• ICCCM

In computing, the X Window System (commonly X11 or X) is a network-transparent windowing system for bitmap displays. ... In computing, the Inter-Client Communication Conventions Manual (almost universally referred to by its initials, ICCCM) is a standard for X Window System clients to interoperate on a single server. ...

External links

• ICCCM: Peer-to-Peer Communication by Means of Selections
• ICCCM: Peer-to-Peer Communication by Means of Cut Buffers
• Xdnd specification