Selections/clipboards

[Havoc Pennington <hp redhat com>]

Hi,

A while ago I posted the attached mail to xdg-list. There was a brief
thread but nothing really came out of it (I'd link archives but they
appear to be broken...) 

Does anyone have any comments? Or should I write this up more formally
and call it correct?

The GNU Emacs maintainer says he's willing to change Emacs to follow
this scheme, at least as much as possible given the weird way Emacs
handles cut-and-paste etc. internally. GNU Emacs and Qt are I think
the main examples of code that don't currently work as described here.

I'd really like to hear from the Qt team on whether they're willing to
modify Qt to let the user set both PRIMARY and CLIPBOARD selections,
and from the KDE team whether they'd be willing to use that
feature. It should be extremely trivial to port apps to this behavior,
a matter of replacing the function that retrieves the QClipboard
representing the primary selection with a function that retrieves the
QClipboard representing the CLIPBOARD selection.

All comments welcome.

Havoc


From: Havoc Pennington <hp redhat com>
Subject: clipboards
To: xdg-list freedesktop org
Date: 03 Oct 2000 20:58:53 -0400
Reply-To: xdg-list freedesktop org


Hi,

This list has been quiet for a while (since the main thing we have
going on is on wm-spec-list), but Emacs recently reminded me of the X
clipboard issue, which is simple enough but worth making explicit,
since many apps are still doing incompatible things.

Thoughts welcome:

X clients do not handle 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 com-
  mands  that take only a single argument and is the principal
  means of communication between clients that use  the  selec-
  tion mechanism.

  The selection named by the atom SECONDARY is used:

  o   As  the second argument to commands taking two arguments
      (for example, "exchange  primary  and  secondary  selec-
      tions")

  o   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 common interpretations of the ICCCM:

 a) use PRIMARY for mouse selection, middle mouse button paste, and
    explicit cut/copy/paste menu items (Qt/QClipboard, GNU Emacs)

 b) 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.

I think interpretation b) is correct. I would summarize it as:
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 main advantage of interpretation b) is
that CLIPBOARD works just as it does on Mac/Windows. And also I think
it's the intent of the ICCCM (though it's hard to know).

a) has the following disadvantages:
 - 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

So I propose the following clarifications:

 - selecting but with no explicit copy should only set PRIMARY

 - middle mouse button should paste PRIMARY

 - 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

 - 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 don't have to be supported either

This gives 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.

Havoc