Re: [Patch] A clipboard daemon for gnome-settings-daemon

On Sat, Sep 06, 2003 at 01:19:11PM +0200, Hongli Lai wrote:
> On Saturday 06 September 2003 13:02, James Henstridge wrote:
> >
> > As Jody has said, it isn't clear that always requesting the clipboard
> > data is a good idea.  Calling apps that work fine broken seems like a
> > cop out.
> I am aware of all this. But I don't see any other easy way to prevent the 
> clipboard content from getting lost.
> The other alternative is make applications transfer data to the daemon before 
> they exit, but this requires modification in all applications (or at least 
> the toolkits; depending on the situation). That's way too much work.
The performance implications far outweigh memory usage here.  While
I agree that it would be nice for most apps to work out of the box
with no modification, some apps need to be able to override that
behavior to be more intelligent about clipboard handling.  If there
were some way to communicate to the clipboard daemon not to pull in
some selections things would be reasonable.

This is not a hypothetical,  Klipper based performance complaints
rank fairly high in Gnumeric's bugzilla.  Sadly, Klipper's author's
proposed solution is to have it ignore content when the content is
large.  Which of course misses the point entirely, beacause the
application is then forced to render it anyway.

> With this daemon, the X clipboard will work very similar to the Win32 
> clipboard. Yes, memory is wasted, but the content doesn't get lost. And so 
> far, I have seen a lot more people complaining about the X clipboard 
> (hundreds) than the Win32 clipboard (nobody; ever heard a user critisize the 
> Win32 clipboard? I haven't).

Have you seen MS Excel freeze for 4-5 seconds when a user says
'select all, copy' in preparation for duplicating a sheet manually ?
Neither have I.

Try forcing gnumeric to render an entire sheet as
    - gnumeric xml
    - OO zip
    - html tables
    - text
That is going to take a long time.  Is having a select-all button
somehow wrong ? or perhaps supporting multiple formats ?

Keeping clipboard content around when applications exit is a noble
goal, but supporting that can not preclude reasonable performance.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]