<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35"> <TITLE>RE: [Annoyances] X-Windows Copy & Paste</TITLE> </HEAD> <BODY> 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 </BODY> </HTML>