Clipboard management

[Lubos Lunak]

On Friday 30 of April 2004 16:14, Matthias Clasen wrote:
> On Fri, 2004-04-30 at 09:00, Lubos Lunak wrote:
> > On Wednesday 28 of April 2004 21:16, Matthias Clasen wrote:
> > > 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.
> >
> >  No, it doesn't, but there's no problem adding it. Is just owning the
> > selection enough, or are there some other requirements? I can't find any
> > documentation on it, other than
> > http://www.faqs.org/faqs/motif-faq/part9/section-21.html , I don't see
> > anything about it in the ICCCM, despite the Motif FAQ saying so.
>
> No requirements beyond those which apply to all manager selections. It
> seems that the "traditional" clipboard managers use the selection merely
> for mutual exclusion.

 Ok then.

> > > 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 2.6.3.
> > >
> > > 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.
> >
> >  I think I have some trouble decriphering what this says. Could you
> > please explain this once again in normal human speech?
>
> 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.

> 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 
http://www.freedesktop.org/Standards/clipboards-extension-spec .

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/