Lubos Lunak writes: > In fact we'd probably need some document explaining how the > clipboard/selection are supposed to work. E.g. according to ICCCM[1] there's > only THE selection, one and only - in other words, if you select something in > one app, it should be the only selected thing in the whole session, the app > with previously selected text should deselect. Yet this doesn't always > happen, and also often selecting using shift+arrows does set the selection, > even though there is something selected. This is inconsistent, and moreover > it's pretty annoying (the deselecting, that is). > > It'd be probably good also to agree on some interpretation with other (Gtk+ > etc.) people and update the description text at [2]. Having more apps > supporting some reasonable behaviour could also help with some Klipper > related problems (like when working with Emacs and having large selected > text). The fact that the selection is global is a difference from Windows/Mac that seems to cause problems, and IMO it's not ideal UI. The selection should really be remembered per-application (or per-document?) if we were starting from scratch. I don't remember if Windows/Mac are per-app or per-document or per-window or what, but they aren't global. However, http://www.freedesktop.org/standards/clipboards.txt agrees with the ICCCM on making it global because making it per-application is backward-incompatible so will break a lot of things. In particular, even if apps start to save their current selection internally, middle-click-paste remains global. This is really confusing. For example, imagine terminals didn't unselect on losing the selection, you'd have a hard time telling what middle-click would paste; say you have 5 terminals open and something selected in 3 of them. A real-world example that always annoys me is that Mozilla never unselects in the location entry when it loses the selection. So I can't tell if I'm going to paste the URL or paste some other random thing I happened to click on. GTK+ 1.2 addressed this by having two selection colors. If a selection was the global selection, it would be highlighted in blue, and you could paste with middle click. If the selection existed inside the app but was not global, it would be highlighted in gray, you could use the Copy command etc. on it but you could not paste with middle click. GTK+ 2.0 dropped this feature, because people didn't understand it, and GTK+ 2.0 has the more standard behavior that the selection highlight color changes to indicate whether the text box is focused. A 2x2 grid (focused/unfocused global/local) of selection colors would be pretty over the top. Anyway, I believe what the ICCCM says, and what clipboards.txt intends to say (though it may be vague still), and what GTK+ 2.0 does, is: - the PRIMARY selection is global; if you select something in one application, the previous selection (whichever app it's in) becomes unselected, so you can tell what middle click will do - "Copy" means the contents of PRIMARY become also available via CLIPBOARD, and PRIMARY is unchanged - "Cut" means the contents of PRIMARY become available via CLIPBOARD, and then the selection gets nuked, so PRIMARY is no longer owned - merely selecting something affects PRIMARY but never does anything to CLIPBOARD (if PRIMARY were synced to CLIPBOARD, then you could not select text then paste over the top of it; and more amusingly, the "Copy" menu item *would not do anything* - this option is basically "auto-Copy") "cut-and-paste doesn't work between X apps" has to be one of the most common user complaints, so I think it's *essential* that all toolkits and apps follow exactly the same spec here by default. If there's an option then fine, though I'm sure some users who toggle the option will proceed to complain about how their clipboard is buggy. ;-) But in any case, please please don't change any aspect of this (in the default configuration) without getting some broad agreement and updating clipboards.txt. We're only just now starting to get everything to converge on the current clipboards.txt so users will stop complaining about it. Mozilla still doesn't drop its selection when it loses ownership of PRIMARY, and GNU Emacs still insists on setting PRIMARY when you cut/copy text, but most things are at least close to right. My .02 anyhow Havoc