Re: X11 'clipboard' sucks!
In comp.os.linux.advocacy, greg margarino
on Tue, 11 Jan 2005 15:11:25 +0000
> Ever since switching to Linux, the crappy X11 clipboard
> has been the bane of my life. It completely sucks![/color]
> Firstly, the historical X11 method of copy 'n' paste is
> limited because if the selection disappears, so does your
> text. Modern WMs and apps try to compensate for this by
> providing a Windows-style copy 'n' paste with data
> that persists in the clipboard even after the selection is
> lost, but what you actually end up with is something
> inbetween the two -- clipboard data that depends not on
> the existence of the selection, but the existence of
> the source app or window itself. This leads to endless
> frustration as you close some app (to make space on the
> screen, usually) only to find Ctrl-V no longer works when
> you go to paste something.[/color]
Ah, now we're getting somewhere. :-)
> As an example of how lame this can be in practise, earlier
> I was using Nautilus' built-in text viewer to view a series
> of text files and copy and paste some lines from those files
> into a gedit window. I copied a bunch of text by selecting it
> and hitting Ctrl-C and then pressed the 'Go up one level' button
> in Nautilus to take a look at the directory. But guess what?
> When I attempted to paste my selection into gedit, the selection
> had disappeared from the clipboard, even though Nautilus was
> still open! This is ridiculous.
> (Go on: deny it, Cola nuts!)
> The Windows clipboard works as a clipboard should. When is Linux going to
> fix its crappy approximation?[/color]
There is much confusion here, of course. The proper place
to direct this question is at the tool/widget authors,
and maybe at the X authors. Linux has little to do with
this particular problem, although it serves as a foundation
for all of them.
I agree that the clipboard model needs a lot of work,
not that Windows' model is perfect -- far from it.
My personal recommendations are these.
 A widget should be able to display one of two selection modes,
assuming black text on white is the standard "non-selected"
[a] The standard white text on black, if the widget owns
the selection atom. ('man XSetSelectionOwner' for the
[b] White text on gray - or black text on gray - if the widget
lost the selection atom. If one pastes into a widget
with gray, the gray text is replaced by the text from
the transmitter, emulating to some extent Windows'
Control/C => Control/V semantics.
Ideally these would be configurable color-wise but I'd have
to look regarding Gnomeisms and Qtisms. I'm familiar with
Athena and Motif, myself, so I'd have to study it for the
 Upon destruction or unrealization[*], a widget should be able
to put its selected text, if it's the selection atom owner,
into the cut and paste buffer
There is admittedly a minor race condition here; a paste
may be requested during a widget's destruction. Note that
mere iconification is not a problem, although the widget
may lose focus.
 If there is no selection owner, or the selection owner has
no selected text, the widget should fetch from these buffers.
 If the widget gains focus it should take the selection atom, if
it has a gray area. It probably should take it even if it does not
have a gray area. (Focus is primarily defined by XFocusIn and
 If the widget loses focus it should either voluntarily give up
the selection atom, or expect to have it taken in the very near
future. It should also transfer its text into the cut and
 All widget systems (Athena, Motif, Qt, Gtk, etc.) should honor
these as conventions.
There are a number of issues here -- for starters,
cutbuffers don't necessarily have to store *text* (an
issue if cutting and pasting from HTML clients, word
processors, or bitmap editors), and UTF-8 encoding may
have to be carefully processed. Also, work may already
be progressing along completely different lines. I don't
know, but I know what I'd personally like to see, and you
do have some valid points which match my own observations.
I do *not*, however, advocating giving up the mouse
buttons; that's a detail that simply indicates where one
should cut and paste, and your above doens't even mention
such anyway. Besides, it takes two less keypresses. :-)
(Mouse1-move-mouse2 versus Ctrl-C-move-Ctrl-V.)
I am crossposting this to increase exposure, and hopefully
someone will respond intelligently to this. It's something
that does need to be fixed. (Unfortunately there's no
Gnome analogue I can find for comp.windows.x.kde.)
I'm thinking of cobbling up a prototype using raw X, and
see how it works from a usability standpoint.
[*] Intrinsics/Athena implements unrealization as destruction of the
widget's window, if memory serves. Presumably KDE and Gnome
have similar issues.
It's still legal to go .sigless.