Murray.Cumming at Comneon.com
Murray.Cumming at Comneon.com
Wed Nov 19 17:30:42 EET 2003
Jody, I think it's your turn.
murrayc at usa.net
> -----Original Message-----
> From: desktop-devel-list-admin at gnome.org
> [mailto:desktop-devel-list-admin at gnome.org] On Behalf Of Lubos Lunak
> Sent: Donnerstag, 13. November 2003 18:07
> To: Jody Goldberg
> Cc: Cumming Murray (Comneon); h.lai at chello.nl;
> desktop-devel-list at gnome.org; merchan at baton.phys.lsu.edu;
> carpdjih at mailbox.zrz.tu-berlin.de; xdg-list at 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 at Comneon.com wrote:
> > > > > From: Jody Goldberg [mailto:jody at gnome.org]
> > >
> > > 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 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/
> desktop-devel-list mailing list
> desktop-devel-list at gnome.org
More information about the xdg