GNOME Bugzilla – Bug 144613
"Copy link address" should update primary selection as well as clipboard
Last modified: 2006-11-19 05:42:54 UTC
Right-click on a URL and select "copy link address". Now try to paste the result into a gnome-terminal or xterm window. It doesn't work, because the selection hasn't been updated. The canonical documents on X clipboard behavior don't specify what should happen in the case of an explicit copy which was not preceded by a selection. But Evolution and Mozilla update the primary selection as well as the clipboard, and that seems like the friendliest behavior.
Created attachment 28838 [details] [review] Patch to update primary as well as clipboard on copy link location
I do not like this behaviour, because it breaks the PRIMARY-is-the-last-selected-text mantra. Unless this becomes a desktop policy, I'd have to take some convincing... (It appears the panel clock is doing this now too, *sigh*)
Well, absent real usability testing it's hard to be sure, but I think updating primary agrees with user intuition more than not. For instance, use "copy link address" in gnome-terminal and then try to paste the result into a mozilla or firefox window. Nothing happens (well, or it goes to the URL from the primary selection if one happened to be in there before), and the user intuition is that "copy link address" is broken. As much as it might be simpler to say that "primary is always the last selected text," I think it's much clearer if actions which update primary are a strict superset of actions which update clipboard. I asked the authors of the de-facto standards documents (xdg-list and jwz) and received agreement that "update primary and clipboard" is the right behavior. See http://freedesktop.org/pipermail/xdg/2004-June/004109.html and its reply. I don't know if the documents will be updated to cover this case, but the general community consensus seems pretty clear.
I -am- aware of your asking, and of previous discussions about this issue. I have asked myself on desktop-devel-list, with mixed results. The most articulate response I've found so far is Owen's (http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00440.html) This is mostly irrelevant, I know, but for the record I find it very annoying that evolution messes with my PRIMARY selection.
I agree with the bug reporter. It should be very fast and simple to copy text from a terminal window into other places, whether the destination is within the window or in other windows. I know it breaks the standard behaviour of Win and Mac where the clipboard is not updated unless the user presses Crtl-C or Copy from a menu. But the terminal is a special case -- since you cannot edit the text with a mouse, it makes sense I think to have this modified clipboard behaviour. Even putty on Windows does it this way. Put another way, why else is a user going to select text in a terminal window? If not to paste the text elsewhere? Put another way, gnome-terminal is a really cool terminal emulator. But losing fast copy / paste via mouse left / middle buttons *really* slows power users down. And most terminal users *are* power users.
Speaking as the bug reporter, I'm not sure that argument has anything to do with my report. gnome-terminal already allows fast copy/paste via mouse left (to select) and mouse middle button (to paste the primary selection). If you're having trouble with this, you've found a different bug. The question is: if you right-click on a URL, select "copy URL", and then try to paste with the mouse middle button, should it work? It's unclear from the documents which describe proper X clipboard behavior; normally explicitly copied text has been selected first, so the clipboard can only be set to what has already been set as the primary selection. These menu copy commands are outlying cases. (At this point, perhaps the most powerful argument for gnome-terminal is that by not updating the primary, it is setting itself up to be an outlier; gnome-panel and mozilla and evolution have already gone in one direction, and on such a fine point of usability, consistency is as important than correctness.)
Yay strict superset. I firmly vote that anytime you set the clipboard, you also set PRIMARY, always, without exception. This is the behavior I expected intuitively. No one ever told me that PRIMARY is only supposed to be set by text selection, and my intuitive mental picture was that the middle mouse click is a short-cut paste as described here: https://listman.redhat.com/archives/xdg-list/2003-August/msg00091.html I want to be sure I am being clear here: I never read Owen Taylor's suggestion before today; I'm telling you that I always assumed it worked like the "short-cut paste" he describes. In my experience, the PRIMARY is fragile as a soap bubble. I expect that if I don't hit that middle mouse button right away, something will wipe out my PRIMARY buffer. Having any operation that sets the clipboard also overwrite the PRIMARY would not be surprising in the least. I am not any kind of usability expert, just an interested GNOME user.
*** Bug 163140 has been marked as a duplicate of this bug. ***
I do not think there is any advantage in breaking with the current ‘spec’. The currently selected thing is on PRIMARY, the last explicit copied thing is on the CLIPBOARD; and, most importantly, if you do not know about PRIMARY you do not care. Btw, GtkLinkButtons do not set PRIMARY when one picks Copy from their context menu... Yes, I know this is a very clear case of argumentum ad verecundiam.