Sharing Selections

[John Meacham]

Selections are one of the most powerful IPC mechanisms provided by the X
server, allowing complex features not seen in other systems such as
content negotiation and lazy generation of content only when it is
created.  However, several issues with their design make common idioms
impossible to implement and their full power is as yet unrealized.
Perhaps the main problem is the inability of applications to 'copy' the
contents of a selection in a non-destructive fashion, by choosing to
receive the data, they must decide on a format and the alternate formats
are lost. 

This should be unsurprising, as the generation of alternate formats
and/or lazy generation of content might require arbitrary computations
by the publisher of the data which the X server or other clients cannot
be expected to replicate. although some problems may be addressed by X
Server extensions such as XFIXES, the fundamental problem of copying
selections cannot be without client participation.


examples of several things which are currently impossible, unacceptably lossy
or inefficient are:

 * having an app which provides multiple clipboards, or a place to
   temporarily place multiple selections for later use.
 * have an app which  is able to accept drag-n-drop's and place them in
   the clipboard (or other holding area), and vice versa, taking the 
   contents of the clipboard and publishing them via drag-n-drop.
 * a proxy for allowing drag-n-drops between screens on a single X
   server
 * saving the contents of the CLIPBOARD in an alternate location
 * saving the contents of a selection after an app owning it exits
 * assigning a global hot-key which swaps CLIPBOARD and SECONDARY
 * assign a global hot-key which copies PRIMARY to CLIPBOARD

the fundamental difficulty is that we would like the ability to work
with and manipulate selections as separate entities, but in fact the
app which holds the selection has complete control over it, so all
interactions with the selection must go through it's owner.

the two parts of this proposal are relatively independent and may be
considered separately or as a unit.

*** Part 1:  copying selections

An owner of a selection (call it 'SEL_A') may advertise a conversion type of 
'CAN_CLONE_SELECTION' if it wishes to participate. 
any client may send such a selection owner a 'CLONE_SELECTION' message
with an atom representing a new selection name (call it 'SEL_B') and a
timestamp. the owner of SEL_A then calls 

XSetSelectionOwner(disp, SEL_B, owner's window, timestamp from message);

and publishes the exact same data on SEL_B as SEL_A. from now on, the
selections are treated independently, losing one does not imply losing
the other and SEL_B may be the source of more clones. 

this protocol would allow many of the type of apps discussed above to be
written, not only could selections be cloned, it is done without sending
any data through the X server, effectively making it 'free' to manipulate
selections. 

An interesting utility that this would allow is a generic 'palette' or
dock app could be implemented which would accept many drops of
arbitrary, even unknown types and  keep them as icons in a window to be
used as the source of drags in the future.  if you are commonly working
on several directories ,with certain colors or with chunks of text or an
arbitrary mix you could create a custom toolbox just by dragging and
dropping them and without lossy conversions or inefficient sending of
data through the X server. AFAIK this sort of app is impossible to write
on windows or macs without actually copying the selection data around.



*** Part 2: Persistence of selection data

In general, since converting data between types and/or generating them
dynamically or lazily could require arbitrary code, the only truly
general way for selections to stick around is for their owner to not
exit, but rather, keep a stub around to hold the selections after the app
quits. However, this is overkill for most types of apps which use
selections for simple blocks of text.

to solve this selections may advertise either of these conversion
targets:

PERSIST_SELF_HANDLED
This means the client handles persistence after its exit itself such as
by wine or xclip. persistence daemons need do nothing. the reason for
it's inclusion is to keep clipboard type apps from harvesting it's
selections prematurely thinking the data would be lost on exit.

PERSIST_COPY_OKAY
this target means that it is okay for a persistence daemon to copy this
data out of the selection. A client wishing to copy the raw data would
do a ConvertSelection to this type, what is returned is a list of atoms
representing the types which should be copied. the persistence daemon
should copy the data from all types listed and advertise the same set of
types when it grabs the selection returning the same raw data.

if neither of these are listed the owner is not participating in this
protocol and the proper behavior of a persistence daemon will have to be
decided by heuristic or user preference. 

A notification ClientMessage could be sent to the persistance manager on
exit, the app would wait for a SelectionClearEvent to be sure the
manager got the data out okay.  

        John

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john at foo.net
---------------------------------------------------------------------------