Clipboard daemon

[Jody Goldberg]

On Mon, Dec 01, 2003 at 03:48:12PM +0100, Lubos Lunak wrote:
> 
>  This means the only potentionally expensive part should be the actual 
> transferring of the data. It should happen relatively rarely, usually with 
> small amounts of data. Problems with large data can be handled by having a 
> limit (hence the max selection size proposal), and also Klipper transferring 
> only the data types it's interested in.
> 
>  If I open here 1MB file in KWrite or gedit, after doing Ctrl+A, Ctrl+C 
> there's one short time of high CPU usage caused by it (<1s, this is Athlon 
> 1600+ running X locally). Not that good, but I find it acceptable. And 
> moreover I consider this to be a rare case - people usually put much smaller 
> data in clipboard.
 

Why bother transfering just text ?  That makes all the rich formats
mostly useless.

Try that operation with kspread or Gnumeric.  1meg is trivial to
generate when you're spewing xml.  Multiply that by a number of
supported formats and the amount of data gets large.

>  IMHO the solution is sufficient, and has the best gain/effort ratio. The only 
> complains about Klipper I remember are its CPU usage when the user selects 
> very large data in the application, and this has been partially already fixed 
> by the improved polling, and the maximum data size would take care of the 
> rest.

Toolkit support for notifying of impending exit so that the
clipboard could save all of the supported formats seems like a
stronger solution.  Gnumeric has recevied alot of bug
reports/complaints when Klipper is enabled.