Re: State of the X clipboard, and perhaps a solution

[Gregory Merchan <merchan phys lsu edu>]

On Thu, Apr 22, 2004 at 05:29:12PM -0500, Jerry Haltom wrote:
<snip>
> To satisfy both requirements imposes a restriction: the data, in
> whatever mime format is requested, must be able to be generated at the
> time of pasting. This requires that the code to generate the proper
> data, and the original data set be in memory or otherwise available at
> the time of pasting.
> 
> And here we get to the answer, maybe. The only way to satisfy the above
> requirements (that I can think of) is to keep the data and code
> available in memory during the duration that it owns the clipboard
> contents. This means long living processes of some sort. The code and
> memory can be offloaded into another process (by virtue of something
> like Corba/Bonobo, or shared libraries loaded by a central daemon). This
> however is a really bad idea and I hope nobody took it serious. Or,
> preferably, the hosting program can just hang around for a bit, until it
> no longer owns the clipboard.
> 
> This would work as follows. Lets use Gnumeric as an example. The user
> opens up a spreadsheet in Gnumeric, and copies a number of rows and
> columns. At this point Gnumeric does whatever it needs to internally to
> store away the copied values. It then informs the X server, through the
> protocols that already exist, that it now owns the clipboard and has
> available a number of mime types. Such as (made up)
> application/x-spreadsheet, text/html, text/plain, text/rtf, text/xml,
> etc. The user then closes the Gnumeric application. At this point,
> Gnumeric does what it usually does when it exits... closing open files,
> unloading settings, disconnecting from gconf, saving configuration, etc.
> Normally the GTK main loop would now exit. However, it should realize
> that the program currently owns the clipboard, so it doesn't end the
> process. The process keeps running. It's got pretty much everything
> unloaded however, so it's memory footprint isn't THAT big. It stays
> alive this way, until it looses ownership of the clipboard, at which
> point it finally exits.
> 
> This idea however makes program shutdown non-deterministic. A user
> cannot be assured that just because he told the program to exits, that
> the real underlying process has in fact exited. I would weight this
> against the benefits of having a really nice fully featured Just Works
> clipboard however. Also, is this really a problem? A user isn't suppose
> to have knowledge about how a process is implemented... he isn't suppose
> to care that a program hangs around in the background when he thinks
> it's closed, likely no user will ever even notice nor care. Worth
> considering is that only one of these sleeping processes will every
> exist at a time (barring implementation of multiple clipboards).
> 
> Anyhow, discuss. I want to hear pros/cons, etc. This proposal doesn't
> require any new specifications of interprocess communication at all,
> simply a modification to the life-cycle of a program... which is handled
> by libraries such as GTK and QT.

When Mike Hearn described the Windows clipboard as working pretty much
the same way, I proposed we do the same for X:

  http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00637.html

Session saving, a shutdown-hand-off method, et al. are discussed in thread.
Interest was minimal, but far worse is that KDE has a different notion of
how the clipboard should work at the user interaction level:

  http://mail.gnome.org/archives/desktop-devel-list/2003-December/msg00009.html
  et seq.

Good luck,
Greg