Clipboard daemon

[Lubos Lunak]

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:
>
> <snip>
>
> >  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 
cheap.

>
> 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:
>   http://www.phys.lsu.edu/students/merchan/GNOME/Recommendations/Clipboard

 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 
disowned.

 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 
rest.

>
>
> Cheers,
> Greg

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
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/