RE: Clipboard daemon

[Murray Cumming Comneon com]

Jody, I think it's your turn.

Murray Cumming
www.murrayc.com
murrayc usa net

> -----Original Message-----
> From: desktop-devel-list-admin gnome org 
> [mailto:desktop-devel-list-admin gnome org] On Behalf Of Lubos Lunak
> Sent: Donnerstag, 13. November 2003 18:07
> To: Jody Goldberg
> Cc: Cumming Murray (Comneon); h lai chello nl; 
> desktop-devel-list gnome org; merchan baton phys lsu edu; 
> carpdjih mailbox zrz tu-berlin de; xdg-list freedesktop org
> Subject: Re: Clipboard daemon
> 
> 
> 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/
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>