Re: Clipboard daemon

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Oct 29, 2003 at 02:46:10PM +0000, Mike Hearn wrote:
<snip>
> There is a key distinction here that you must realise:
> 
> * The OLE clipboard on Windows is scoped local to a PROCESS not a WINDOW *
> 
> The reason everybody hates the X clipboard is because it's window scoped.
> For instance, if I type something into an Evolution mail window, copy it,
> create a new message window then try and paste it in, it'll work only as
> long as the original window exists. This has bit me several times.
> 
> If the clipboard persisted as long as Evolution did, really this would not
> be a huge problem.

Selection ownership is tied to an X window, not a window in the sense of
what the window manager handles. That X window is tied to a connection to
the X server. As long as an app maintains that connection and that X window,
it can retain the clipboard.

For the purposes of selections, a window is just a number that identifies
some data.

(Short form: There's a bug in Evolution's clipboard handling.)


> There are a few other complexities involved - for instance the clipboard
> is implemented using DCOM (remoting interfaces into other
> processes/threads/machines like Bonobo), which means that if you paste
> some complex information into a document as a link, the originating app
> will be kept alive through reference counting until the app you pasted
> into is quit (or serializes the object into a file and no longer needs the
> source running).

That's easy enough to do:

  GNOME Policy Number 0xF00
  -------------------------
  A. A program MUST NOT disconnect from the X server while it retains
     ownership of the clipboard, unless told to do so by the session
     manager.
  B. Upon receipt of a session shutdown signal, whichever program
     owns the clipboard MUST store the clipboard data in such a way
     that it can retrieve the data when a session is restored.
  C. A program which owned the clipboard on session shutdown MUST
     retrieve the clipboard data and reclaim ownership of the
     clipboard when the session is restored.
  D. A program SHOULD store a retrievable form of the clipboard
     data while it owns the clipboard, so that it may recover from
     abnormal termination.


<snip>
> Merging Honglis patch into gnome-settings-daemon would be a good first
> step. It might not be perfect, but I'd rather increase resource usage than
> lose the users work, which unfortunately is a nasty consequence of this
> bug. I've lost work because of this before, and it is extremely annoying.

Extra resource consumption isn't the only loss from naive clipboard
managers; responsiveness is also lost while the data is being transferred.

Use of something like _MOTIF_SNAPSHOT reduces the amount of data to be
transferred and can also provide for at least one form of stored data
to persist outside of the cutting application.

A hand-off-when-terminating protocol would also reduce transfer lags and
could provide persistence of data in multiple forms.

A snapshot protocol could be combined with a hand-off protocol too.


> Longer term, it might be worth rethinking the clipboard model, and perhaps
> making it independant of X (as really it's not a windowing system feature
> at all, it's an application feature).

The first goal of X may have been graphics, but it's really a network-
transparent inter-process communication system which happens to be
able to draw colorful frames around terminal emulators that don't fill
the entire screen. ;-)


> Final note - clipboard and drag'n'drop are two faces of the same thing in
> almost every OS and windowing system. It might be worth trying to unify
> them at the user interface level too one day.

At the user interface level?  I don't understand.


Cheers,
Greg