Re: Clipboard daemon
- From: Jody Goldberg <jody gnome org>
- To: Lubos Lunak <l lunak suse cz>
- Cc: merchan phys lsu edu, Murray Cumming Comneon com, h lai chello nl, desktop-devel-list gnome org, carpdjih mailbox zrz tu-berlin de, xdg-list freedesktop org
- Subject: Re: Clipboard daemon
- Date: Mon, 1 Dec 2003 11:47:29 -0500
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]