New clipboard proposal

[Philip Van Hoof]

Hi there fellow hackers, programmers and other people involved in the
development of the freedesktop.

There's been many problems with the current implementation of the X11
clipboard. Before I start with my new proposal I'll guide you through
the current implementation so you'll understand some terminology. If you
already know everything about the clipboard on X11, you can skip all
this, of course.

Very very short . . .

There's three standard clipboards: The PRIMARY, SECONDARY and the
CLIPBOARD. Another name for such a clipboard is "a selection". So you
say "the CLIPBOARD selection".

Only one xclient application can own such a clipboard at a time. All
three work independent from each other.

When an xclient requests the selection, it will typically ask X about
the selection-owner of a specific selection (PRIMARY, CLIPBOARD or
SECONDARY).

Such a selection-owner can advertise the formats it's supporting. Those
formats are called TARGETs. One selection-owner can have multiple
targets. It can advertise the supported ones in a standard target called
the TARGETS target. 

So a typical requester (an application that is going to paste something)
will first ask for the TARGETS target, then it will pick a format it
knows, then it will ask the selection-owner to start converting data to
the format it had been advertising. Then it will retrieve this data from
that selection-owner through the xserver.

Lets take an example:

In Mozilla you selected some text. Thats the PRIMARY selection.

In Evolution's E-mail composer you do "paste". Evolution's E-mail
composer will now ask X about the selection-owner. Through X it will ask
for the TARGETS target of that selection-owner (Mozilla). 

Mozilla will say it supports a "text/html"-target.

Evolution's E-mail composer will request Mozilla to convert it's own
format to that "text/html"-format and Evolution's E-mail composer will,
through X, receive the data in the requested format.

There's many problems with this method:

o. What happens when Mozilla got shut down before Evolution got
   the chance to paste the clipboard?

o. What happens when Mozilla has 400MB of data to deliver? A better
   example might be "copying a large table from
   gnumeric to Mozilla composer"

o. What happens when you shutdown your X session. Is your
   clipboard lost?

To address these issues, I've cooked up a proposal. The proposal aims to
replace the entire clipboard in the long run. But will provide full
backwards compatibility for older X-clients. The proposal won't depends
on any technology disliked by both KDE or GNOME.

The proposal itself is incomplete. There's still a lot to agree upon.

The proposal

o. We'll still use the current protocol for advertising the fact
   that there's support for the new-type clipboard. There's no problem
   with still using the old-style clipboard.

o. We add a TARGET "x-extension/dbus"

o. The contents of the target explane the available
   services on dbus. The format of the contents isn't
   defined yet.

o. We'll create a library that will do most for the application
   developer

o. That library will initiate dbus in such a way that both
   xclients/processes can enjoy the wonders of inter process
   communication. This will address the "large clipboards" issue.

o. The library will fallback to the oldstyle X11 protocol if the
   dbus connection failed. This way it isn't necessary to let
   dbus serve on tcp/ip or to open ports. If both processes
   aren't on the same host, it will use the current (working)
   implementation.

o. A clipboard manager will, using the new Xfixes extensions,
   catch clipboards that will be lost if the selection-owner
   gets destroyed. That same clipboard manager will persist
   the clipboard when the session is about to get shutdown. 

o. Whether or not to support a clipboard history is an option or a
   plugin for that clipboard manager.

o. The clipboard manager can also function as a hybride between
   old X11 applications and newer applications. The clipboard
   manager can, for example, add the "x-extension/dbus" target and can
   provide a service that will deliver the data if a newer application
   wants to receive the data using that channel.

I attached two dia diagrams. You can view them using the app "dia" which
is available here: http://dia.sf.net. They might be incomplete or
inaccurate or whatever. And no there's not really anything done yet
(except a very basic sample application using the new XFixes events
related to clipboard handling).



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: normal new situation.dia
Type: application/x-dia-diagram
Size: 2830 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041230/613782bd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: owner destroys situation.dia
Type: application/x-dia-diagram
Size: 2673 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041230/613782bd/attachment-0001.bin>