l.lunak at suse.cz
Mon Dec 1 16:48:12 EET 2003
On Friday 28 of November 2003 17:18, Gregory Merchan wrote:
> On Thu, Nov 13, 2003 at 06:07:25PM +0100, Lubos Lunak wrote:
> > On Monday 10 of November 2003 20:14, Jody Goldberg wrote:
> > > On Mon, Nov 10, 2003 at 07:41:17PM +0100, Lubos Lunak wrote:
> > Klipper is not xclipboard, it does not snatch any things. It just keeps
> > a history of them.
> Then it seems all discussion so far has been cross-purposes.
> Klipper is polling the selections? It must be, because the XFixes
> extension isn't widely deployed. (The XFixes extension sends an event when
> a selection is claimed.) Or, it relies on a private protocol to receive
> notification of changes.
Actually Klipper tries to make use of everything that could help, including
Qt's internal protocol which tries to solve the lack of selection
notifications. And as the last thing, it has to poll the selection, yes. The
point is, it's enough just to poll for the selection timestamp (well, unless
the owner app is so bad that it even doesn't have the timestamp target, then
it has to transfer the actual data). I consider that to be sufficiently
> What GNOME has been talking about is a clipboard manager using the same
> basic protocol as xclipboard and Motif's clipboard. That is a program
> that claims the manager selection CLIPBOARD_MANAGER and the selection
> CLIPBOARD. When it loses the CLIPBOARD selection, it requests data from
> the new owner, and upon receipt of that data it reclaims the CLIPBOARD
> selection. Through loss and reclamation of the CLIPBOARD selection, it
> knows when new clipboard data is available.
Aha, now it makes sense, I thought it was already clear Klipper doesn't work
this way. It's not my fault you've choosen the inferior solution :).
> My solution is here:
Ugh. That seems way too complicated to me (especially the part about what
every program must do - what would be the framework good for, if every app
had to do things on its own?).
Let me sum up how Klipper works: It checks whether the clipboard contents
have changed, by using XFixes, selection timestamp, whatever, while trying to
transfer the actual clipboard data. Only if it changes, Klipper transfers
what it wants to transfer, and that's about it. Klipper takes selection
ownership only if you select something from its history, or the selection is
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.
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
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the xdg