Re: Clipboard daemon

[Lubos Lunak <l lunak suse cz>]

On Monday 10 of November 2003 20:14, Jody Goldberg wrote:
> On Mon, Nov 10, 2003 at 07:41:17PM +0100, Lubos Lunak wrote:
> > On Friday 07 of November 2003 14:28, Murray Cumming Comneon com wrote:
> > > > From: Jody Goldberg [mailto:jody gnome org]
[snip]
> >
> >  So? It's still much better to get it wrong by magnitude than making
> > Klipper ignore it _always_ , including plain selections in lineedits and
> > similar. Maybe it's not obvious from the wording of the spec, but wildly
> > inaccurate guesses are still ok.
>
> Having an application's content show up in the clipboard daemon
> sometimes seems less intuitive to me than having it not show up at
> all.  Either way you'd need an affordance in klippy's ui to indicate
> that content was ignored.

 I'm not sure about less intuitive, but it would be definitely more useful, 
especially with high enough limit, where it would be next to always.

>
> There are other issues raised previously which did not make it into
> the thread here.
>
> 1) To be useful klipper is forced to request all forms of the data.
>    Including little used formats which require me to load extra code
>    from plugins.
>     eg we can paste to OOo format, or html, or XL xml ...
>    All of these translations are in external modules, and should
>    only get loaded and run when necessary.

 Actually Klipper currently only requests text, so it's not going to request 
any xml or whatever. But I don't see a problem with that - if a user runs a 
daemon capable of and configured to fetch everything that appears in the 
clipboard, they probably want it. As long as there's still some reasonable 
top limit, so what? Should Gnumeric be different just because you don't want 
it to load some modules?

>
> 2) There are also spreadsheet specific issues with the nature of
>    cut-n-paste that are broken by having a clipboard daemon snatch
>    things.  The content in a spreadsheet contains references to
>    other cells, and more importantly other cells contain references
>    to it.  When the content is cut then pasted between spreadsheets
>    those references are updated.  When they are pasted into a
>    non-spreadsheet the result is different,

 Klipper is not xclipboard, it does not snatch any things. It just keeps a 
history of them.

>
> >  If you have any better idea, I'd like to hear it; we can ignore
> >  that proposal linked above, it's just a proposal after all,
> >  without any real implementation yet (AFAIK). However, as far as I
> >  can say, it'll be usually better than your solution, and it's
> >  guaranteed to be never worse.
>
> My proposal has long been that clipboard daemons only be invoked
> when an app exits while holding the selection.  That leaves the
> content in the application with the most knowledge of how to handle
> it as long as possible.

 The only difference between this and Klipper I see is that with your way one 
cannot keep clipboard history.

>
> If some notion of a clipboard stack is needed then a fall back to an

 It is. That's the reason we have Klipper after all.

> opt out policy seems reasonable.  It could even be optional, with a
> semantic of
>     'warn user that this content is expensive'

 That's more or less what the maximum data size proposal is about.

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