Clipboard management

[Lubos Lunak]

On Wednesday 05 of May 2004 21:22, Matthias Clasen wrote:
> On Wed, 2004-05-05 at 14:31, Lubos Lunak wrote:
> > > 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

 Yes.

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

 Yes, I didn't say that explicitly, but it wouldn't be needed anymore.

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

 No, it doesn't in this case (when trying to keep history or know the current 
clipboard contents for any other reason). In all other cases that ICCCM 
suggest would be sufficient, but not here. If you have text in OOo, and you 
press LMB, and start moving, it acquires the selection immediatelly. Klipper 
detects this (it polls the TIMESTAMP target right now, XFIXES wouldn't 
actually change that much about it), and fetches the data. However, if 
Klipper manages to do this while you're still doing the selectin in OOo, it 
gets data before you release LMB. There's no notification at all after LMB is 
released, so Klipper in fact doesn't have the current clipboard contents.

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