Re: X clipboard

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes:  
> 1) the server could also use provide the standard X CLIPBOARD selection
>    to provide compatibility.

It doesn't work to mirror to the X selection - it's one big race
condition. It has to provide the selection _primarily_ via X, with
possible mirror to other stuff, but I don't know of any features that
are gained by mirror to other stuff.

> 2) The problem is (here is where my crack smoking could have affected
>    my memory) that in X if you say cut something from document A in say
>    AbiWord, then save the file, close abiword, open say KWord, and
>    say 'paste', you will be unpleasantly supprised that there is NOTHING
>    to paste.  And you've lost the data.

clipboard.txt acknowledges that issue. The possible solutions are:
 - "xclipboard" (as the ICCCM itself suggests) - a clipboard 
   server that takes over selections immediately.
 - something like xclipboard except it only takes over selections 
   on app exit, using some sort of protocol
 - your suggestion here: 
> The app knows when it holds the clipboard.  If the user closes the app, the
> app would not close until something else got the clipboard.  It would
> just close all it's windows and just work as a something to provide the
> clipboard data if someone asks for it.

When I said a clipboard server is bad, what I meant is that a
nonstandard clipboard protocol is bad.

For plain text, to avoid the "lose clipboard on exit" issue you can
just run "xclipboard" right now today.

Havoc