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

[Owen Taylor <otaylor redhat com>]

Darin Adler <darin eazel com> writes:

> X has made good progress since the old days toward having easier to use copy
> 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)

> 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 since
> it's a limitation not shared by other platforms.

It's a problem that anybody who has worked with X on the desktop is well
aware of.

But it isn't a simple "doh, we didn't think of it" problem - the real
problem is the very nature of the X selection mechanism - the choice
of format is delayed until the contents. To simply store the data
somewhere would end up with:

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

I'm not claiming these problems are not unique to X. In windows,
people may remember the dialog that pops up when 

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.

> Basically, if you copy text from a window, then close that window, then
> paste, the text is gone. This is also true within GTK. Once the widget goes
> away, text copied from the widget is gone.
> 
> I'd like to know if anyone has the intention of addressing this problem in
> GTK or maybe at the GNOME level and I figured I'd ask here. Should I write a
> bugzilla.gnome.org bug report about this?
 
Well, addressing it at the GTK+/GNOME level sounds good, but
really not possible without addressing it the X level, or without
losing large amounts of interoperability.

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

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

Then, to get consensus on this, and build on top of it in GTK+/GNOME.
It's someone vaguely on my "projects to do someday", but not
near the top of the stack.

> I heard from Pavel Cisler that there's some kind of solution for this
> problem in Motif. 

Interesting. Never heard of such a thing. 

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

However, this an old legacy mechanism, which is missing most of the
functionality of the X selection mechanism

> Will fixing this require some kind of special daemon or
> something? Is there a straightforward fix that won't require a lot of code
> changes in application code?

It will almost certainly require changes in both application and 
library code, since there is no concept "storing" the selection
on exit.

Regards,
                                        Owen