[Owen Taylor <otaylor redhat com>] Re: copied item going away when you close the window you copied from

[Owen Taylor <otaylor redhat com>]

[ Accidentally sent this just to Keith, so resending ]

Keith Packard <keithp keithp com> writes:

> > > 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.

I don't remember the details, but I do know that on windows,
these effects only occur on application exit - which is a
lot better than always.
 
> >  - 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.

Yep. But I think there are applications (the GIMP, etc) where
these tradeoffs are not acceptable, so I don't think a system
daemon that always steals the clipboard is going to work.

> > 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.

Confusion between PRIMARY and CLIPBOARD is the root of all X selection
evil. Or at least most of it.

The opinion that should be promulgated is that CLIPBOARD is the
clipboard, and that PRIMARY is just a short-cut way of pasting
that X experts can use. 

See:

  http://www.freedesktop.org/standards/clipboards.txt

(Not a real standard, just guidelines Havoc wrote up to try and end
the rampant confusion on this issue.)

[ Clients such as older versions of Qt and FSF emacs have caused no
end of confusion and lack of interoperabiilty by making cut/copy/paste
menu items affect the PRIMARY selection, not 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.

Sure, and by GTK+. But I don't think it is really enough by itself.
 
> > (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.

It is a reliable mechanism if you are willing to live
with the consequences of the clipboard manager always taking back
the CLIPBOARD selection. And it is pretty simple.

But I think the user shouldn't have to decide between:

 - The limitations of fixed external storage of the clipboard
   contents.

 - Loosing clipboard contents on application exit.

globally for the entire desktop without assistance from the
applications. I think a more dynamic mechanism (and most likely more
complex) for preserving clipboard contents is needd.

Regards,
                                        Owen