State of the X clipboard, and perhaps a solution



We all know it sucks. And if we don't know that, we're in denial. I've
been pondering a bit on the "proper" way to handle clipboard
communication, and wanted to submit my idea, which has probably already
been thought of by somebody else, to this list, to perhaps provoke some
discussion.

This all started when my boss (who now runs Gnome), started complaining
about how retarded the clipboard is.

The features I think we REQUIRE in a good clipboard implementation are
as follows:

1. Content negotiation. A copying program must be able to advertise what
data types (mime types) it supports. A pasting program must be able to
retrieve the data in any mime type it also supports.

2. Clipboard survives on application close. When an application or
document or dialog or other UI component from which the user made a
selection and a copy ceases to exist, the clipboard data must be
preserved. Including content negotiation. The user should not be aware
of "how a clipboard works", or "what the rules are". It should Just
Work, as expected. Copy/paste... nothing more.

I think both of the above are required for a good, consistent, clipboard
implementation. I think to expect, or settle for less wouldn't be
reasonable.

The first requirement is handled by the current implementation. A
copying program is able to advertise what types it supports, and a
pasting program is able to make a determination which type it wants. The
second requirement however has eluded us. A number of approaches have
been tried, all which suffer from a lack of consistency from the user's
perspective.

The most traditional, probably most often thought up idea is to use an
escrow daemon of some sort... such as the Gnome Clipboard Manager. This
solves the second condition and immediately breaks the first. This is
when the copying application offloads it's data into a long running
daemon, to hold it. Usually it's the long running daemon which requests
the data from the copying application. The long running daemon takes
ownership of the clipboard, and pasting applications consult it to
paste.

The problem here is what data type do we send to the escrow daemon? The
primary one? All of them? The only proper answer, in order to satisfy
requirement 1 is to send all the data. This however is not reasonable.
We could be talking about a multi-gigabyte movie file, or audio data. Or
maybe audio data available in 4 different audio formats. This is
immediately obvious as not being practical to offload to a escrow.

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.



Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]