Re: Selections/clipboards

["Bradley T. Hughes" <bhughes trolltech com>]

On 9 Nov 2000, Havoc Pennington wrote:

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

Hey Havoc,

I've already changed (what will be) Qt 3.0 to follow the bahavior
described below.  Matthias Ettrich forwarded your mail to xdg-list
and it's already done ;)

I can't speak for the KDE team, but the semantics change will be easy to
cope with (QClipboard's API only gained 2 new methods to accomdate this
change)

> 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
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
> 

--
Bradley T. Hughes <bhughes trolltech com>
Trolltech AS - Waldemar Thranes gt. 98B N-0175 Oslo, Norway
Office: +47 21604892
Mobile: +47 92019781