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

[Keith Packard <keithp keithp com>]

Around 1 o'clock on Feb 24, Owen Taylor wrote:
> 
> 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.

Windows is a bit tricky in this; it requires that the application prepare 
the data for the clipboard, but it may not transmit it to the window 
system at that time.  That's because of the weird Win3.1 API where the 
application allocated space for the selection and held onto it.

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

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.

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

It's certainly a big part of it; not helped by the fact that the core 
clients didn't have cut/copy/paste semantics using the CLIPBOARD.

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

PRIMARY is not a short-cut, it's a different model.  PRIMARY is the locus 
of the users intent.  Every time you select anything on the screen, that 
application should assert PRIMARY.  I would go even farther and suggest 
that any time the locus of activity moves, the PRIMARY selection should 
follow; click in a text widget, and the PRIMARY selection should return 
what page/line/file the user is typing at.

CLIPBOARD is designed to hold data aside the screen, away from the locus 
of user activity.  It may be echoed in some remote window or entirely 
hidden.

Of course, this means that cut/copy/paste editing should assert PRIMARY 
when the selection is made, assert CLIPBOARD when the selection is cut/
copied and deassert PRIMARY when the region is unselected.  Which agrees 
with your model as far as CLIPBOARD goes, but also asserts PRIMARY for 
applications that want to use that model.

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

ACK!  Make them stop...  Of course, emacs could only interact through the 
CUT_BUFFER properties for a long time; I guess this is an improvement?

> > > 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.  This doesn't fix the catastrophic client failure mode, but only an
external CLIPBOARD agent would solve that.

> 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.  Alternatively, Gtk 
could force the application to hang around until the CLIPBOARD selection 
was lost.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.