Clipboard management

[Matthias Clasen]

On Wed, 2004-05-05 at 14:31, Lubos Lunak wrote:
> 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).

I don't see any hints in the ICCCM that DELETE should be omitted from
TARGETS. But anyway, I agree that the manager should try to avoid saving
targets which make no sense. As you say, that includes not only side
effect targets, but also metadata like TIMESTAMP.

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

Oh, I had overlooked that footnote. 

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

So your proposal is that the CLIPBOARD owner should offer a target, say
TARGET_LENGTHS, which would get a list of targets as parameter and would
return a list of target-length pairs ? (allow the fallback to listing
the sizes of all TARGETS if no list of targets is specified...)
We could avoid the extra roundtrip by changing the property specifying
the save-worthy targets to be a list of target-length pairs, but a) that
would leave the manager without size information if the app doesn't
specify the targets to save and b) you seem to be interested in
requesting the sizes of the targets not only in the handover-before-exit
situation, but also when harvesting clipboard contents for a history

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

This sounds more like the proposed TARGET_LENGTHS target would replace
the _NET_MAX_SELECTION_SIZE mechanism rather than complement it. 

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

Well, the ICCCM says

  "The division between these two cases is a matter of judgement on 
   the part of the software developer."

so you should simply apply good judgement and  reacquire the selection
ownership. I'd add that you should also reacquire the selection if
relevant metadata changes, e.g. the set of targets. This is necessary to
properly (de)sensitise "Paste" menu entries, for instance. Regarding the
timestamp/notification issue, XFIXES takes care of that.


Matthias