Dominik Honnef

Clipboards

Last modified:
by

X11

Active protocol. Clients own selections (CLIPBOARD or PRIMARY; there is also SECONDARY, but nobody seems to use it. Also technically there’s an infinite number of selections, identified by atoms, but only CLIPBOARD and PRIMARY are widely used), clients interested in selection contents send request to owner. Requestors use XConvertSelection to request the selection contents in a specified type. Types are specified as atoms, and are either well-known names such as UTF8_STRING, or commonly mime-types. The semantics of selections are specified in ICCCM, not X itself. The special target TARGETS causes enumeration of all types supported by the owner.

Responding to a selection request is done by writing into a property specified by the requester. Large data transfers are meant to happen in chunks, using the INCR type.

Most desktop environments run some kind of clipboard manager (such as xclipboard or klipper), which turn the active protocol into a seemingly passive protocol for the CLIPBOARD selection, by immediately requesting the data when the selection owner changes and storing it. TODO: figure out how that works with different types.

Wayland

Only specifies the equivalent to X11’s CLIPBOARD, explicitly doesn’t want PRIMARY for security and usability reasons. However, https://wayland.app/protocols/primary-selection-unstable-v1 exists.

macOS

NSPasteboard. Doesn’t use mime types but UTIs, whatever that is.

Windows

WASM