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