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

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

> Around 1 o'clock on Feb 24, Owen Taylor wrote:

> > 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.
> 
> The original selection design was predicated on being able to run more 
> than one application at a time...

I don't follow this. While I typically would keep both apps
open while cutting and pasting between them, I don't think
this should be required of my users...

> Perhaps what you want is a gnome-specific agent which transfers the 
> selection on application shutdown.  That could be as simple as using 
> another selection name to perform the transfer.

See below on why I think this needs to be standardized.

[ description of the intent of PRIMARY snipped ]

> > > > 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 to handle applications which want their selections to survive their 
> demise.  Of course, if by "demise" we mean "well ordered shutdown", then 
> Gtk could fix the problem by simply hanging around until CLIPBOARD is 
> lost. 

The mental model presented to the user is that there is a single
global clipboard. Thus, the user is entitlted to expect that
_every_ clipboard selection survives application demise.

The confidence of users in the correct operation of their desktop
requires that stuff that is put in the clipboard stays there.
A lot of programmers have trouble with the concept that the
X selections are "virtual" clipboards, not real clipboards.

I have no expectation that users will figure that out; if stuff
vanishes from the clipboard, they will just decide the the X
clipboard is buggy.

> This doesn't fix the catastrophic client failure mode, but only an
> external CLIPBOARD agent would solve that.

I don't think we need to worry about that, or, at least less than we
need to worry about loosing unsaved changes on catastrophic client
failure.

> > 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.
> 
> No, but perhaps a simple agent could be built which uses the same 
> principles that Gtk could use on application shutdown.  It would transfer 
> CLIPBOARD to itself when specifically directed to.

Well, a clipboard client that took ownership of the clipboard selection
on demand is basically what I'm envisioning here, by "a more
complex mechanism". 

This doesn't go quite far enough if you want to also allow the
other functions of XClipboard:

 - Keeping a history of past contents

 - Displaying the current contents of the clipboard.

Because X has no way for a 3rd-part to monitor changes in selection
ownership. That could be resolved by forcing clients to send
notification (with consequences for backwards compatibility),
by a protocol extension, or by simply having the clipboard client
poll.

I think there is a need for standardization here because if each
toolkit and environment invents their own extensions to the
CLIPBOARD protocol, there will be problems with them stepping
on each other heels, and any XClipboard replacements will
simply not interoperate.

And also, when a GTK+ client is running within the KDE desktop, I
really cannot expect the GTK+-clipboard-saver to be running.

> Alternatively, Gtk 
> could force the application to hang around until the CLIPBOARD selection 
> was lost.

Possible, but I think it is problematical for the programmer to
have to worry about managing a "exited but not really state"

And it's problematical to the user; the user might take some action after
"exiting" the application that prevents the application from supplying
the selection (like unplugging his laptop from the network)

Regards,
                                        Owen