www/ Specifications/ ClipboardsWiki

Historically, X clients have not handled cut-and-paste in a consistent way, leading users to believe that X doesn't even have a working clipboard. This isn't really accurate; there is a conventional behavior, somewhat standardized in the ICCCM. But many apps don't follow the conventional behavior.

X has a thing called "selections" which are just clipboards, essentially (implemented with an asynchronous protocol so you don't actually copy data to them). There are three standard selections defined in the ICCCM: PRIMARY, SECONDARY, and CLIPBOARD.

The ICCCM defines these as follows:

"The selection named by the atom PRIMARY is used for all commands that take only a single argument and is the principal means of communication between clients that use the selection mechanism.

The selection named by the atom SECONDARY is used:

  • As the second argument to commands taking two arguments (for example, "exchange primary and secondary selections")
  • As a means of obtaining data when there is a primary selection and the user does not want to disturb it

The selection named by the atom CLIPBOARD is used to hold data that is being transferred between clients, that is, data that usually is being cut and then pasted or copied and then pasted."

In addition, the ICCCM has a thing called "cut buffers" which most clients no longer support.

There are two historical interpretations of the ICCCM:

  1. use PRIMARY for mouse selection, middle mouse button paste, and explicit cut/copy/paste menu items (Qt 2, GNU Emacs 20)
  2. use CLIPBOARD for the Windows-style cut/copy/paste menu items; use PRIMARY for the currently-selected text, even if it isn't explicitly copied, and for middle-mouse-click (Netscape, Mozilla, XEmacs, some GTK+ apps)
    • No one ever does anything interesting with SECONDARY as far as I can tell.

The current consensus is that interpretation 2 is correct. Qt 3 and GNU Emacs 21 will use interpretation 2, changing the behavior of previous versions.

The correct behavior can be summarized as follows: CLIPBOARD works just like the clipboard on Mac or Windows; it only changes on explicit cut/copy. PRIMARY is an "easter egg" for expert users, regular users can just ignore it; it's normally pastable only via middle-mouse-click.

The rationale for this behavior is mostly that behavior 1 has a lot of problems, namely:

  • inconsistent with Mac/Windows
  • confusingly, selecting anything overwrites the clipboard
  • not efficient with a tool such as xclipboard
  • you should be able to select text, then paste the clipboard over it, but that doesn't work if the selection and clipboard are the same
  • the Copy menu item is useless and does nothing, which is confusing
  • if you think of PRIMARY as the current selection, Cut doesn't make any sense since the selection simultaneously disappears and becomes the current selection

Application authors should follow the following guidelines to get correct behavior:

  • selecting but with no explicit copy should only set PRIMARY, never CLIPBOARD
  • middle mouse button should paste PRIMARY, never CLIPBOARD
  • explicit cut/copy commands (i.e. menu items, toolbar buttons) should always set CLIPBOARD to the currently-selected data (i.e. conceptually copy PRIMARY to CLIPBOARD)
  • explicit paste commands should paste CLIPBOARD, not PRIMARY
  • possibly contradicting the ICCCM, clients don't need to support SECONDARY, though if anyone can figure out what it's good for they should feel free to use it for that
  • cut buffers are evil; they only support ASCII, they don't work with many clients, and they require data to be copied to the X server. Therefore clients should avoid using cut buffers and use only selections.

Apps that follow these guidelines give users a simple mental model to understand what's going on. PRIMARY is the current selection. Middle button pastes the current selection. CLIPBOARD is just like on Mac/Windows. You don't have to know about PRIMARY if you're a newbie.

I don't think there's a sane mental model if we collapse everything into PRIMARY and ignore clipboard, see rationale above.

A remaining somewhat odd thing about X selections is that exiting the app you did a cut/copy from removes the cut/copied data from the clipboard, since the selection protocol is asynchronous and requires the source app to provide the data at paste time. The solution here would be a standardized protocol for a "clipboard daemon" so that apps could hand off their data to a daemon when they exit. Or alternatively, you can run an application such as xclipboard which constantly "harvests" clipboard selections.

References:

-- Main.?BillSpitzak - 11 Dec 2003 (copied with cleanup changes only from clipboards.txt)

Another interpretation becoming popular is to say the PRIMARY selection is really ?DragAndDrop, with the advantage that you can rearrange windows and open/close them between the "drag" and the "drop". In fact this makes a lot of sense, and is even coded already in how XDnD interacts with older programs (drop will do a middle-mouse-click in older programs)

-- Main.?BillSpitzak - 11 Dec 2003

The problem of clipboard "volatility" is a little worse than is described above. The reasoning behind the asynchronous transfer protocol used by X cut-and-paste is that the source and destination apps will want to negotiate the "best" format that both sides can handle. The 1980s Macintosh model (IIRC) was that there was a single preferred format for each clipboard datatype that all applications that handled that datatype were expected to support. This enabled putting just one representation on the non-volatile clipboard. This is arguably the right thing for X to do also. It seems likely that UTF-8 is the preferred text format, PNG the preferred format for bitmap graphics, TTF for fonts. Other cases are harder to decide. Someone needs to standardize them :-).

-- Main.BartMassey - 10 Feb 2005

The obvious way to standardize the X clipboard is to use standard internet MIME types, which seems to be the direction it is going. Most people agree that we need some sort of standardized clipboard manager. In order to hold data from closed applications, it will have to decide what data types to negotiate. Therefore, it makes sense for the clipboard manager specs to include management of the preferred clipboard data types.

-- Main.?JoeKrahn - 09 Dec 2010

X application copy/paste proposal for atom SECONDARY

Extend default X copy paste functionality to include paste over highlight without breaking current mouse-highlight (copy) mouse middle-click (paste) methods.

Practical use for the atom SECONDARY. If mouse-highlight (HL) data is different from contents of atom PRIMARY, duplicate atom PRIMARY into atom SECONDARY and put content of (HL) in atom PRIMARY. Then on (HL) middle-click if (HL) is same as atom PRIMARY contents paste data from atom SECONDARY.

This keeps the existing behavior, implements additional features and is not difficult to implement. Since atom SECONDARY is mostly unused this would be a good use for it - IMO.

-- FriscoRose - 10 Nov 2005

I completely agree here. Middle-clicking into highlighted text only makes sense if it can automatically paste the previously highlighted text. However, it seems that many developers want to move away from the middle-click paste and just use the MS-Win/Mac-OSX approach of requiring keyboard input to copy/paste.

IMHO, it makes sense to continue supporting middle-click pasting for those who find it useful, but it may also be useful to update the cut/paste standards such that those who don't want it can disable it. Perhaps there could be a formal Paste event, or just a WM-protocol hint that tells applications which mouse button represents a paste.

-- Main.?JoeKrahn - 09 Dec 2010