Active and passive selections
The methods for transferring data can be classified into active and passive, depending on whether the client handling the selected data has to actively participate in the transfer to a client requesting it: ; Passive: When some data is selected, the client handling the window where this selection is done transfers it somewhere, and no longer needs to care about it; ; Active: Transfer of data to a client requires the client "holding" the selection to actively participate in the exchange. Selections and drag-and-drop are active mechanisms: after some text is selected in a window, the client handling the window must actively support a protocol for transferring the data to the application requesting it. By contrast, cut buffers are a passive mechanism: after some text is selected, it is transferred to a cut buffer and remains there even if the application handling the window terminates and the window is destroyed. The X clipboard is a passive mechanism as perceived by the client holding the selection, but requires thexclipboard client to actively support any subsequent data transfer.
An advantage of active mechanisms is that the data can be converted to a different format before the transfer. In particular, the client receiving the data can request the selection data to be converted into a suitable form. If the sending client refuses to do so, the receiver can request a different format. For example, a piece of text rendering HTML code can be transferred as text to a requester that can only handle text, but can also be transferred as HTML code if the requester can handle it. Such negotiation of format cannot be done by passive mechanisms, in which the client holding the selection (and giving it semantics) transfers the selection and is not involved in the further transfer into a client requesting it.
Another advantage of the active mechanisms is that large pieces of data can be transferred in a sequence of transfers rather than a single one. Passive mechanisms instead require all data to be transferred somewhere from the selection owner, then transferred again to the client requesting it.
The advantage of the passive mechanisms is that the transfer can be done even after the client holding the data terminates. This is not possible in the active mechanisms, which require the client holding the data to actively participate in the transfer.
Selections
The X Window System supports an arbitrary number of selections; every selection is identified by a string (more precisely, anatom). The most used selection is the PRIMARY selection.
The following requests are specific to selection transfer, although transfer also involves other requests:
# request to know which window owns the selection
# request to set the window that owns the selection
# 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 must tell the server that the window is the owner of the selection.
When the user tries to paste the selection into another window, that window's handler initiates a protocol for getting the selected text from the other client. This protocol involves the second and third requests of the list above, and is not specified by the X protocol but as a convention in the Clipboard
The most used selection is thePRIMARY selection, and is used when the user selects some data. The CLIPBOARD selection is used when the user selects some data and explicitly requests it to be "copied" to the clipboard, such as by invoking "Copy" under the "Edit" menu of an application. An associated request of "Paste" results in the data of the CLIPBOARD selection being used.
At the level of the core protocol, the PRIMARY and CLIPBOARD selections do not differ. But the xclipboard client makes them behave differently. In particular, when another client asserts the ownership of the CLIPBOARD selection, this program requests and displays it in a window. Any further request for this selection are handled by xclipboard. This way, the content of the selection survives the client having copied it.
Cut buffers
Cut buffers are another mechanism to transfer data, in particular selected text. They are window properties of the root window, namedCUT_BUFFER1, etc. Unlike selections, 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 called CUT_BUFFER1. When the user pastes the text in another window, the window owner reads this property of the root window.
The xcutsel program transfers data between selections and cut buffers, and the xcb program allows various kinds of access to the cut buffers.
Cut buffers are considered obsolete.
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. Drag-and-drop is complicated by what happens during the drag. Namely, when the user drags the selection to different parts of the desktop or a window, the user expects to be able to tell whether text can be dropped or not. In particular, the target should display visual feedback on whether or not it will accept the drop, and the cursor should change to indicate the action that will be taken; e.g., copy or move. In the Xdnd protocol, the window where the text is selected and the drag begins is called the ''source''; the window over which the cursor hovers is called the ''target''. The communication between the source and the target is driven by the source because the source "grabs" the cursor. An exchange between source and target is therefore necessary in order for the target to even know that drag-and-drop is happening. Since the source decides the shape of the cursor, the source must receive a response from the target in order to update the cursor. In addition, since the target may need to draw a bombsight to indicate where the drop will occur, and since acceptance of the drop may depend on the exact location of the cursor, this exchange must happen repeatedly as the cursor moves. In fact, even if the cursor does not move, messages must be exchanged to allow the target to scroll when the cursor is near an edge of the viewing area. Otherwise, the user will only be able to drop on the visible portion of the target. A program can state that a window can be the target of a drop by creating a property namedXdndAware which contains the highest version of the protocol that the program supports. This way, applications which support newer versions can fall back to older versions in order to interoperate correctly. In addition, all applications that are written without support for Xdnd will be ignored.
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
While 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, respectively
If the user drops, the target requests the selection from 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.
In summary, 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.
XDS
The ''Direct Save Protocol'', abbreviated ''XDS'' (for ''X'' Window ''D''irect ''S''ave Protocol), is a software protocol that supports saving files by dragging them to file manager windows. XDS is built on top of thePrograms
The following programs specifically operate on data transfer mechanisms: * xcutsel transfers data from selections to cut buffers or vice versa * xclipboard,See also
* X Window System protocols and architecture * X Window System core protocol * ICCCMReferences
External links