Re: X clipboard
- From: Havoc Pennington <hp redhat com>
- To: George <jirka 5z com>
- Cc: David Faure <david mandrakesoft com>, Diego González <dggonz yahoo com>, Gnome Components <gnome-components-list gnome org>, xdg-list freedesktop org, granroth kde org, nolden kde org
- Subject: Re: X clipboard
- Date: 21 Dec 2001 09:20:23 -0500
George <jirka 5z com> writes:
> 1) the server could also use provide the standard X CLIPBOARD selection
> to provide compatibility.
It doesn't work to mirror to the X selection - it's one big race
condition. It has to provide the selection _primarily_ via X, with
possible mirror to other stuff, but I don't know of any features that
are gained by mirror to other stuff.
> 2) The problem is (here is where my crack smoking could have affected
> my memory) that in X if you say cut something from document A in say
> AbiWord, then save the file, close abiword, open say KWord, and
> say 'paste', you will be unpleasantly supprised that there is NOTHING
> to paste. And you've lost the data.
clipboard.txt acknowledges that issue. The possible solutions are:
- "xclipboard" (as the ICCCM itself suggests) - a clipboard
server that takes over selections immediately.
- something like xclipboard except it only takes over selections
on app exit, using some sort of protocol
- your suggestion here:
> The app knows when it holds the clipboard. If the user closes the app, the
> app would not close until something else got the clipboard. It would
> just close all it's windows and just work as a something to provide the
> clipboard data if someone asks for it.
When I said a clipboard server is bad, what I meant is that a
nonstandard clipboard protocol is bad.
For plain text, to avoid the "lose clipboard on exit" issue you can
just run "xclipboard" right now today.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]