Re: Clipboard daemon

[Jody Goldberg <jody gnome org>]

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]
> > >
> > > > > I could try making the daemon to check for a special
> > > > > "_DONT_SAVE" atom
> > > > > (or something like that)...
> > > >
> > > > When I asked Klipper maintainer, he pointed out this freedesktop.org
> > > > specification:
> > > > http://www.freedesktop.org/Standards/clipboards-extension-spec
> > > > which he is happy to implement instead.
> >
> > By the way, here is some discussion of that specification:
> > https://listman.redhat.com/archives/xdg-list/2002-November/msg00039.html
> >
> > > > Does this seem to be a suitable solution?
> > > >
> > > > It pleases me that a KDE hacker had to point out a freedesktop.org
> > > > specification to GNOME hackers.
> > >
> > > The Klipper fellow has mentioned that proposal before.  Sadly
> > > it is mostly useless unless the application pretends.  The
> > > mechanism it proposes requires the app to approximate how
> > > much content will be produced.  Doing even an approximate
> > > measurement will require the loading of all of the supported
> > > clipboard exporters, which is part of what I want to avoid.
> > >
> > > It's only use, as far as I can tell, is to lie and set the
> > > max to 0 as a proxy for 'OPT_OUT_OF_CLIPBOARD_MANAGEMENT'.
> > > Using an ultra coarse approximation
> > >     eg number_of_cells x 1k + sum(embedded_images)
> > > is going to produce wild overstatements for most formats
> 
>  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.
 
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.

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,

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

If some notion of a clipboard stack is needed then a fall back to an
opt out policy seems reasonable.  It could even be optional, with a
semantic of
    'warn user that this content is expensive'
although that would not solve (2).