[Annoyances] X-Windows Copy & Paste

[Richard Boulton]

On Thu, 2003-08-21 at 14:20, Havoc Pennington wrote:
> The problem that does need solving is persistence of clipboard after
> an app exits, ideally without harvesting a selection and freezing its
> format immediately.

I can think of lots of solutions - but none are without problems.

1) Use cut buffers.
   This is supported by some terminal applications, and not much else.

Pros: Simplicity. Doesn't require any new processes/protocols.
Cons: Only works for text.
      Possibly has some size of data limitations.
      Text is unformatted and has to be assumed to be in Latin1.
      The data has to be copied even if noone wants it.
      Needs lots of application changes, since few currently bother to
      look in cut buffers.

2) Define and use a new mechanism like cut buffers, but that supports
   formatted data.

Pros: Could be made to work with images, etc. Could store the data in
      XProperties still, or use XProperties to point to where to go to
      get the data.
Cons: Needs whole new system to be built.  Also, the data has to be
      copied even if noone wants it.  Forces data to be converted to a
      single format.

3) When an application is about to exit, it could spawn a process to
   sit around holding the contents of the clipboard.  This process would
   exit as soon as it loses ownership of the clipboard.
   This is actually done by wine, and seems to work quite well.

Pros: The format of the data doesn't have to be constrained at all.
      No overhead except for when application exits whilst owning
      clipboard.
      Allows the data to persist in multiple formats.
Cons: Requires a process to stay around after application exits
      (particularly a problem if the application was on a remote
      connection which is being severed - eg, an ssh tunnel).  It also
      requires all applications to do some fairly complex coding (or use
      a shared, new, utility library).  It also fails to make the
      clipboard persist if the application crashes, or is killed without
      a chance to spawn the new process. 

4) Similar to (3), but instead of the application spawning a process,
   if an application is about to quit and owns the clipboard, it would
   advertise in some way that it would like to pass the clipboard on to
   someone else.  This could be done by setting an XProperty, perhaps.

   You could then have a "clipboard persistence manager" process which
   listens for changes to the XProperty, and when it sees one it grabs
   the contents of the clipboard, and claims ownership.  Once it's
   safely got the clipboard, the application may exit.

Pros: Doesn't require complex coding on part of applications (just
      requires them to set an XProperty, and not to exit before
      selection can be copied.)

Cons: Requires a manager process to be running: if there isn't one, not
      only will the clipboard be lost, but also the application won't
      lose the clipboard, so won't know to quit.
      Forces the data to a single format.
      Doesn't protect clipboard data against application crashes or
      vicious kills.

5) The current solution; run a clipboard manager which grabs the
   clipboard as soon as it is set.

Pros: Doesn't require any application changes.
      Works acceptably.
      Allows features such as a clipboard history to be built in.
      Clipboard persists even if application crashes.
Cons: Forces clipboard data to a single format.
      Performs much unneccessary copying of data.
      Requires a manager process to be running.

6) Add to X a mechanism for an application to receive notification of
   X selection changes.  Then, run a manager application which
   copies the contents of the clipboard whenever it is set - but doesn't
   do the current thing of claiming the clipboard ownership.  Only if an
   application dies whilst holding the clipboard will the manager claim
   ownership of the clipboard.  Basically, the manager provides a
   "backup" of the clipboard data.

Pros: Doesn't require application changes.
      Allows features such as a clipboard history to be built in.
      Doesn't force clipboard data to a single format.
      Clipboard persists even if application crashes.
Cons: Requires modification of X.  (At least, I can't find any way to
      get notification of selection changes without claiming the
      ownership first.)
      Performs unneccesary copying to clipboard.
      Requires a manager process to be running.


I think option 5 is what we have to live with for the moment, and option
6 would be better except for the need to modify X.

I'd actually like the ability to get notifications of selection changes
for other purposes than the above too (specifically, I'd like to make an
application which searched documentation databases for the contents of
the current selection, and instantly presented links any useful
information it found in a small window on my screen).  So if anyone
knows a way to do it, let me know. ;-)

-- 
Richard