RE: Clipboard daemon
- From: Murray Cumming Comneon com
- To: l lunak suse cz, jody gnome org
- Cc: 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
- Date: Wed, 19 Nov 2003 16:30:42 +0100
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
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]