CLIPBOARD selection doesn't save content
glynn at gclements.plus.com
Sun Apr 4 16:17:30 PDT 2010
> > 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
> 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
Glynn Clements <glynn at gclements.plus.com>
More information about the xorg