Re: Clipboard daemon

[Jody Goldberg <jody gnome org>]

On Fri, Oct 31, 2003 at 04:38:50PM +0100, Hongli Lai wrote:
> Murray Cumming Comneon com wrote:
> 
> >I'm frequently confused by the various X clipboard systems [1], but ...
> >
> >It looks like Hongli is saying "my daemon doesn't use PRIMARY" and Jodi is
> >saying "Gnumeric doesn't use PRIMARY". So where's the problem?

Yay, neither of us use PRIMARY :-)
Becauase we both use CLIPBOARD.

> My daemon only gets data from CLIPBOARD. If Gnumeric doesn't put 
> anything on CLIPBOARD then I don't see why it would result in large data 
> transfers if you're just selecting some cells.

Gnumeric does use CLIPBOARD.

My only request for a clipboard daemon is that there is a way to opt
out.  For the record the reasons are that

1) Some apps can produce a huge amount of data
    eg fill a row in gnumeric, select it, and hit copy.

2) It can be expensive to render things into all possible different
   formats (which is what you need for an effective daemon).  As an 
   eg gnumeric can render clipboard output as
    - simple text (various encodings)
    - gnumeric xml
    - html
    - OO xml
   and will likely be adding more clipboard formats in the next
   development cycle.  We do not even _load_ the code to generate
   all of those unless something requests it.  So I definitely to
   not want a solution that will immediately force all of these
   external filters to be loaded, and run for minimal gain.

We've been over this ground several times.  If you want a daemon
there must be a way to tell it to keep its sticky little fingers off
of things.  Only applications that manually opt out need any special
handling, so there should be no worries about massive compatibility
problems.  When an app opts out, it can easily giveup and regrab the
selection just before exit, and disable the opt-out flag for that
last time.

How about a magic target type in the list of possible formats as a
flag ?  It would be trivial to support and should be acceptable to
Klippy people too.