Re: copied item going away when you close the window you copied from

[Keith Packard <keithp keithp com>]

Around 16 o'clock on Feb 23, Owen Taylor wrote:
> 
> Darin Adler <darin eazel com> writes:
> 
> > X has made good progress since the old days toward having easier to use cop
> y
> > and paste for novice. We have the cut/copy/paste menu items as well as the
> > old parallel middle-click copying machinery. 
> 
> (The cut/copy/paste mechanism has been in X for about 10 years)

It's a feature, not a bug :-)  Phil Karlton designed the X selection 
mechanism to solve many problems, mostly involving unnecessary data 
conversions and transmissions.  I wrote a paper on how they work and
why they're useful:

	http://www.xfree86.org/~keithp/talks/selection.ps

> > But we still have this problem
> > where the copied item goes away if the window you copied from goes away. I
> > hope I don't have to convince anyone here that's a problem, especially sinc
> e
> > it's a limitation not shared by other platforms.

It's not an intrisic limitation of the X selection mechanism, only in how 
it's usually used.  The ICCCM defines a mechanism to provide a persistant 
selection that survives application shutdown.  Using the CLIPBOARD 
selection, a separate agent can hold the contents of the selection in 
several formats to act as an intermediate agent between the selection 
provider and consumer.

There's a standard X client 'xclipboard' which manages this selection,
automatically updating it's copy whenever another client places data into
it.  Clients requesting the clipboard contents will receive it from the
clipboard client.  Note that, unless the clipboard client happens to fetch 
the data in the right format, you will generally lose information in this 
transfer.  This is how other platforms always work, so it's no worse, it 
just doesn't do as well as X selections generally can.

>  - Keeping 1 or more extra copies of the data. (Think if you have a 40 meg
>    image on the GIMP clipboard)
>  - Fossilizing onto a subset of the data types.
>  - Preventing more complex interactions between source in dest.
>    (E.g. - When doing local copies within a single GtkTextView, the 
>    data is never serialized, allowing extra information to be 
>    preserved.)

This is precisely what the xclipboard client causes.

> But, any solution is going to involve something more complex than
> just sticking the data. At a minimum you want to keep the selection
> as it is now, and hand it off when the application exits.

The client is free to assert both PRIMARY and CLIPBOARD; the target 
client can first request PRIMARY and if no selection exists, it can 
then request CLIPBOARD.

> I think the approach that needs to be taken is to figure out how to
> address it at the X level.

The CLIPBOARD mechanism is already supported by the standard XFree86 
clients.

> (Not very simple, and may even require an X extension to do reliably,
> since the X selection mechanism has some problems with tranferring
> selection ownership.)

The ICCCM describes how the CLIPBOARD transfer is managed.

> Some apps, like xterm, use something called "cut buffers", which
> basically consist of sticking text in a property in the root window.

Yes, there are cut buffer properties on the root window (and the magic 
"RotateProperties" request as well for kill-ring operation).  These should 
not be used; use CLIPBOARD instead, at least you can transfer more than a 
single format.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.