[Annoyances] X-Windows Copy & Paste

[Giles Atkinson]

Richard Boulton wrote:


> I've found this a most interesting discussion.

> To summarise, my understanding is that applications should set PRIMARY to
the contents of the selection whenever it is modified, and set CLIPBOARD
only on an explicit user command.  Whenever CLIPBOARD is set, PRIMARY should
also be set to the same thing (but this probably happens implicitly anyway,
since the usual way to set CLIPBOARD involved making a selection first).

> Applications should paste from CLIPBOARD if an explicit paste is done (eg,
from a menu), but may support an alternate method for pasting from PRIMARY,
such as middle button click.  CLIPBOARD is the copy&paste mechanism that
must be implemented to ensure interoperability with all applications -
therefore applications must simply provide some means of setting CLIPBOARD
in order to be able to paste into all other applications.

> The "explicit action" to set CLIPBOARD could be a keyboard shortcut, a
toolbar menu option, a context menu option, or possibly something else, as
long as it is an explicit step that the user takes to perform the copy.
CLIPBOARD should not be set simply by making a selection, since this is too
destructive of data deliberately copied by the user.

> The only time it would be excusable to set CLIPBOARD on selection without
an explicit action would be if there was absolutely no way that such an
action could be built into the UI.  However, I don't know of a situation
where this is the case: for a terminal application for example, at least one
of a right-click context menu or a keyboard shortcut would be appropriate.


> An appropriate patch to Pterm to make it support the above would be:
> * Leave the current behaviour of setting PRIMARY on selection with the
>   left button, and pasting from PRIMARY on the middle button.
> * Add context menu options for "cut" and "paste", which work only on
>   CLIPBOARD, and have no interaction with PRIMARY.

> This seems neat, and hopefully avoids confusing users.  It also avoid the
risk that when I'm pasting from one pterm to another I slip and press the
wrong mouse button (particularly common when using "emulate 3 buttons"), and
lose my selection.

> I think I've got it clear enough in my head I can write a patch now, and
convince the maintainers to accept it.  Thanks for that.


This seems fine except that most XDG-compliant applications will also be X
applications
and as such should be compliant with the ICCCM.  I think this is part of the
point that
Havoc was making.  The ICCCM is explicit on the PRIMARY selection:

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

Only a small change to Richard's text is needed.
In the third paragraph above it should be enough to change "but may" to "and
must" here:

"... but may support an alternate method for pasting from PRIMARY,
such as middle button click."

The appeal to existing standards also makes it clear what is really wrong
with the
Mozilla/pterm/Wine example: Wine ignores the primary selection.  Its not
clear what the
right behaviour is for an emulator, but Unix-style middle button paste would
probably be more useful in practice that the Windows middle-button actions.

There is also a more interesting issue of usablility here.
I have been somewhat surprised at the view that
middle button paste is some sort of frill for experts.  Am I alone in
finding the
traditional X-windows actions (slice/move/click) a vastly superior user
interface to
the Mac/Windows slice/control-c/move/control-v, with hands moving between
mouse and keyboard?  (Of course in practice that is often
slice/control-c/move/click edit/click chevrons/click "paste special"/
click "text"/click OK, thanks to the inclusion formatting by default,
but that is another story.)  We have a genuinely superior interface and
should make the most of it, not treat it as an anachronism to be hidden.

Giles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20030820/d7b8f6e3/attachment.htm