Useful (?) information on the clipboard, selection, copy and paste, drag and drop

[Randy Kramer]

I came across this on, iirc, an xdg list on which I lurk:

Specifications/ClipboardsWiki 
(http://freedesktop.org/wiki/Specifications/ClipboardsWiki)

It was useful to me in getting some idea about how the clipboard (should) work 
in X (and hints at the mechanisms that make it work).  Below are some quotes.  

Perhaps some of the information will be useful to someone looking into the 
"anomalies" that seem to occur with the clipboard and so forth in nedit 
and/or when nedit is used with other applications.

I don't know if I ever mentioned one of my problems:  I use klipper (I don't 
know if that's relevant), and sometimes when copying something from nedit to 
some other application (or vice versa, but I don't think I see it as often in 
that direction), klipper and the target application "hang" for a fairly long 
time.  By hang, I mean that the klipper "icon" in the toolbar disappears for 
up to 60 seconds, and during that time, I can't paste, and, for example, if 
I'm trying to paste into kmail, kmail is hung for that same period of time.

I suspect that some of this problem is due to what they call the asynchronous 
approach to cut and paste in X / Linux.  Iiuc, when you cut or copy something 
it is not immediately put in a place (I hesitate to use the word buffer, 
since it may have a more specific connotation in this context) from which it 
can be pasted.  Instead, it is not until the paste occurs (or is attempted) 
that the text is actually "extracted" from the source document.  

Having written that out, maybe that's not the problem.  Still, the information 
or the apparently new recommendations might be useful.  (Or maybe it's all 
old stuff. ??)

Anyway, some quotes (there is more stuff in the document):

<quote>
Application authors should follow the following guidelines to get correct 
behavior: 
   * selecting but with no explicit copy should only set PRIMARY, 
never CLIPBOARD 
   * middle mouse button should paste PRIMARY, never CLIPBOARD 
   * explicit cut/copy commands (i.e. menu items, toolbar buttons) 
should always set CLIPBOARD to the currently-selected data (i.e. conceptually 
copy PRIMARY to CLIPBOARD) 
   * explicit paste commands should paste CLIPBOARD, not PRIMARY 
   * possibly contradicting the ICCCM, clients don't need to support 
SECONDARY, though if anyone can figure out what it's good for they should feel 
free to use it for that 
   * cut buffers are evil; they only support ASCII, they don't 
work with many clients, and they require data to be copied to the X server. 
Therefore clients should avoid using cut buffers and use only selections.

...

A remaining somewhat odd thing about X selections is that exiting the app you 
did a cut/copy from removes the cut/copied data from the clipboard, since the 
selection protocol is asynchronous and requires the source app to provide the 
data at paste time. The solution here would be a standardized protocol for a 
"clipboard daemon" so that apps could hand off their data to a daemon when 
they exit. Or alternatively, you can run an application such as xclipboard 
which constantly "harvests" clipboard selections.
</quote>

I presume klipper is probably similar to xclipboard in constantly "harvesting" 
clipboard selections, which means my suspicions about the cause of the kmail 
hangups may not be true.

But, it would be nice to have all this stuff "just work".

Randy Kramer