CLIPBOARD selection doesn't save content

[Glynn Clements]

Quintus wrote:

> > Apart from implementing the CLIPBOARD selection, the application
> > should implement the SAVE_TARGETS protocol for optimum behaviour with
> > modern clipboard managers. For details, see:
> 
> OK, I've done so (hopefully).
> 
> > http://www.freedesktop.org/wiki/ClipboardManager
> 
> After rereading this document, I think I finally got how the mechanism
> works. Can you confirm this:
> 
> 0. The clipboard manager acquires the CLIPBOARD_MANAGER and CLIPBOARD
> selections.
> 1. My application acquires CLIPBOARD, acting just as if it were PRIMARY.
> 2. My application wants to exit. Therefore, it
> 	1. Sets a property, say, "MY_SELECTION", to the targets it
> 	wants the clipboard manager to preserve the content.
> 	2. Requests the X server to convert the CLIPBOARD_MANAGER
> 	selection to SAVE_TARGETS, by passing my application window
> 	and the MY_SELECTION property.
> 3. The clipboard manager gets notified (by a SelectionRequest event) and
> now queries my application for each target I set MY_SELECTION to.
> 4. The clipboard manager sends my application a SelectionNotify event
> with property SAVE_TARGETS (or None if it has failed to save the
> content) indicating that is has completed
> 5a. The clipboard manager takes ownership of the CLIPBOARD selection
> 5b. (parallel to 5a) My application exits

I believe this is correct, but I haven't actually written low-level
selection-handling code since the SAVE_TARGETS protocol was created.

> In the end, "my application" hopefully is just my function, otherwise I
> would have to go to subprocesses.

Yes. From the X server's perspective, a function which opens a
connection, runs an event loop then closes the connection is
indistinguishable from a more typical client. Successive calls to that
function would appear as distinct short-lived clients. The server only
sees connections; what happens on the client side of those connections
is irrelevant.

-- 
Glynn Clements <glynn at gclements.plus.com>