[Owen Taylor <otaylor redhat com>] Re: copied item going away when you close the window you copied from
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Cc: Keith Packard <keithp keithp com>
- Subject: [Owen Taylor <otaylor redhat com>] Re: copied item going away when you close the window you copied from
- Date: 24 Feb 2001 01:48:03 -0500
[ 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]