Clipboard management

[Lubos Lunak]

On Wednesday 05 of May 2004 18:13, Matthias Clasen wrote:
> 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 ?

 Actually, I'm not sure what x-kde-cutselection is exactly, I don't know that 
code. Let's just not be specific and say that there are targets are make no 
sense at all to be saved, because they either don't contain any real data 
(TIMESTAMP,... actually DELETE etc. come only in requests and are not listed 
in TARGETS, so I don't know many more here) or the data makes sense only when 
the app runs (when doing DND inside a listview).

 Maybe there should be a list of targets to ignore and a list of targets that 
are recommended to save?

> 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.

 You're right, I didn't realize the manager needs to know the size beforehand.

> There is a 
> LENGTH target in the ICCCM, which could be used for that purpose.

 LENGTH is in fact deprecated, just read the footnote in the ICCCM. That 
doesn't mean we couldn't create a new one without its flaws.

> 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'd rather see it in the manager. If you want to have a limit but don't want 
to see a dialog, it's simpler to hit "don't ask again" once. The only 
technical difference in this case is having one more roundtrip asking for the 
size(s) first. How about having a request listing targets and the reply would 
include their sizes (pretty vague guesses would do, as the 
_NET_MAX_SELECTION_SIZE says)?

 That way the manager would find out which targets are available and their 
sizes, and then do all the magic of selecting what to fetch.

>
> 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 ?

 You can do whatever you want with _NET_MAX_SELECTION_SIZE. The only existing 
implementation is a patch on my HDD. I proposed this target to avoid Klipper 
problems with fetching large clipboard contents when one does Ctrl+A in 
Gnumeric or selects large amounts of text in Emacs (I don't remember anybody 
complaining about KDE apps, maybe the Qt notification about clipboard changes 
reduces the problem). After being added it got discussed again (in November, 
see 'clipboard daemon'), and the Gnumeric people didn't like it, for IMHO 
rather strange reasons ("Gnumeric would have to load plugins to handle the 
formats, and I don't want that" - if I as a user have a clipboard daemon 
running which fetches everything it can, I probably don't care).

 With having the request per data type they'd possibly like it more, Klipper 
right now fetches only text, so it would ask only about it. I hope we agree 
that if clipboard contents are to be saved by the clipboard manager, there 
should be some kind of finding out the sizes in order to be able to limit the 
sizes, and do so in one central place. Especially if the daemon also keeps a 
history.

 Which is actually what Klipper is. KDE people don't see it as something that 
keeps the clipboard contents after the app exists, most of them probably 
don't even know there is such a problem. They see Klipper as something that 
keeps history of texts in clipboard (and e.g. I use it several times a day). 
And let's not forget the feature of selecting some text and performing some 
action with it, mostly URL opened in a browser. This needs knowing the 
current clipboard contents as well.

 While I'm already at it, I recently noticed a small problem with finding out 
current clipboard data. The ICCCM uses (in its usual vague way) that if the 
selected data can be seen reasonably same as the old one, the client doesn't 
need to reaquire the selection. Which means that if one spends selecting text 
in OOo for 5 seconds, there's no other way how to find out when the clipboard 
contents have changed, other than really polling all the time, or trying some 
ugly hacks like checking mouse button being pressed. Would it be ok to add a 
new target which would provide the time of the last _real_ change of the 
contents, unlike TIMESTAMP?

-- 
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/