Clipboard problems (yes, again)

Havoc Pennington hp at redhat.com
Thu Oct 31 04:08:01 GMT 2002


Lubos Lunak <l.lunak at suse.cz> 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






More information about the kde-core-devel mailing list