Clipboard management

Matthias Clasen mclasen at
Wed May 5 19:13:04 EEST 2004

On Tue, 2004-05-04 at 09:51, Lubos Lunak wrote:

> >
> > Ok, so the idea is that if a CLIPBOARD owner is about to exit, it
> > requests to convert the CLIPBOARD_MANAGER to SAVE_TARGETS. The side
> > effect of the conversion is that the clipboard manager collects the
> > contents of the CLIPBOARD, takes over the ownership of the clipboard and
> > offers the same content. For additional flexibility, the dying clipboard
> > owner has a way to specify what targets the clipboard manager should
> > harvest, by specifying the list of targets to harvest in the property
> > named in the conversion request.
>  Maybe it should be explicitly said that SAVE_TARGETS should include 
> everything in TARGETS minus targets that don't make sense after the app 
> exists (all those application/x-kde-cutselection and similar which are used 
> only when doing copy&paste inside the app). At least I don't see any other 
> use for this, and things like trying to be smart and avoiding image/xpm when 
> image/png is available should be rather done by the clipboard manager.

I don't think the clipboard manager is the right place to decide the
relative importance of targets. I'd prefer to have it treat the data in
the various formats just a binary blobs, not start interpreting the
meaning of the targets... although we should maybe change the wording 
so that the application-specified targets to save are a "strong
recommendation", but allow clipboard managers to try to be smart and
harvest different targets, if they really want.
The one thing we need to specify though is that the clipboard manager
must not try to harvest well-known side effect targets, like DELETE,
INSERT_SELECTION. I guess application/x-kde-cutselection is also a side
effect target, right ?

> > Basically, SAVE_TARGETS is a way for the clipboard owner to say to the
> > clipboard manager "I'm about to exit, take over the my clipboard
> > contents and the clipboard ownership".
> > > > If an application needs to exit while owning the CLIPBOARD selection,
> > > > they should request the clipboard manager to take over the ownership of
> > > > the clipboard, using the SAVE_TARGETS mechanism, unless the user
> > > > explicitly specified to discard the clipboard contents. If there is no
>  Is this supposed to be the "you have large data in the clipboard, 
> keep/discard?" dialog? Wouldn't it be better to have this in the clipboard 
> manager too? I can already see one app having the limit at 1k, second at 10M, 
> third configurable and fourth one not asking at all. Having it in the 
> clipboard manager would of course require having something like 
> .

I don't think _NET_MAX_SELECTION_SIZE as specified would help you with
that, since it is only a way for the clipboard manager to limit the
amount of transferred data. To have the manager pop up a keep/discard?
dialog when appropriate, there must be a way for the application to tell
the manager the approximate size of the clipboard data. There is a
LENGTH target in the ICCCM, which could be used for that purpose. 
Or do you mean that the app would pop up the dialog, based on the 
limit received from the manager via _NET_MAX_SELECTION_SIZE ? 
If that is the purpose, it might be more straightforward to simply offer
the MAX_SELECTION_SIZE as a conversion target on the CLIPBOARD_MANAGER
selection, and demand that apps respect that value when deciding whether
to pop up the dialog.

I'll attach a slightly revised draft, which takes care of the
side-effect target issue, but doesn't address the other issues yet. 
Speaking about drafts, does anybody object to merging my
CLIPBOARD_MANAGER spec with Lubos' _NET_MAX_SELECTION_SIZE mechanism and
putting it in the wiki ?



-------------- next part --------------
Protocol for handing off the clipboard to a daemon if the clipboard owner exits

- Have a manager selection CLIPBOARD_MANAGER
- Require clipboard managers to own CLIPBOARD_MANAGER
- Require clipboard managers to support a side effect target
  SAVE_TARGETS, which lets the clipboard owner request that the
  clipboard manager collects the content of the clipboard and takes
  over ownership of the clipboard, offering the same content. To
  make this a little bit more flexible, the clipboard owner can
  specify a list of targets to collect.

In order to move forward with solving the clipboard problems, here is a proposal
to codify the existing practice of using the CLIPBOARD_MANAGER selection to
ensure mutual exclusion for clipboard managers. This manager selection already 
is supported by the classic xclipboard client, the Motif clipboard manager and 
gcm. I don't know if Klipper uses it currently.

In order to support handing over clipboard ownership when the clipboard owner
exits, I propose to use a side effect target on the manager selection.

Clipboard Manager Specification

Responsibilities of clipboard managers

Clipboard managers will acquire ownership of a selection named
CLIPBOARD_MANAGER, as described in section 1.2.6 of the ICCCM. Clipboard
managers should comply with the conventions for "Manager Selections" described
in section 2.8 of the ICCCM. The intent is for clients to be able to request a
variety of information or services by issuing conversion requests on this

Clipboard managers should support conversion of the SAVE_TARGETS target on their
manager selection. This is a side-effect target, as described in ICCCM section

When a clipboard manager receives a request to convert the manager selection to
the target SAVE_TARGETS, the named property specifies a list of targets to
convert the CLIPBOARD selection to. If the named property exists, it must be of
type ATOM and contain the list of targets. If the named property does not exist,
the list of targets should be obtained by converting the CLIPBOARD to the
TARGETS target, excluding side effect targets like DELETE, INSERT_PROPERTY 

When handling SAVE_TARGETS, the clipboard manager should convert the CLIPBOARD
selection to all the targets specified by the named property. Then it should
take over ownership of the CLIPBOARD selection and offer the saved conversion
results under the same targets they were requested with.

Responsibilities of clipboard owners

If an application needs to exit while owning the CLIPBOARD selection, they
should request the clipboard manager to take over the ownership of the clipboard,
using the SAVE_TARGETS mechanism, unless the user explicitly specified to 
discard the clipboard contents. If there is no clipboard manager, or if the
SAVE_TARGETS conversion fails, the application should simply exit.

More information about the xdg mailing list