Clipboard daemon

[Lubos Lunak]

On Saturday 13 of December 2003 19:26, Murray.Cumming at Comneon.com wrote:
> > Jody Goldberg wrote:
> > > Lubos Lunak wrote:
> > >  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.
>
> I'll try to revive this again with a little summary as I understand it:

 Sorry, I've been a bit busy with bugfixing for the approaching KDE release.

>
> - Klipper's solution is to limit the amount of data taken.
>   But gnumeric must do a lot of processing just to find out how much data
> would need to be sent.

 Something like
 size ~= fields_selected * average_field_size * some_constant 
 is hardly a lot of processing. It doesn't need to be exactly the number of 
bytes, in fact it doesn't matter if the guess is wrong by 50% in either 
direction. The intention is to avoid transferring a lot of data, and +-50% 
doesn't change anything on a lot being still a lot.

> Personally, I think a clipboard daemon should accept 
> that fact and not demand that gnumeric or other applications should be
> changed. I think a complete application-specific opt-out is not
> unreasonable.

 Only if you don't mind that you select some text in one field in gnumeric, 
and it's also not saved in the history.

 
 Hmm. I still personally believe limiting the data size is sufficient in 
practice, but I guess trying to find a better solution can't hurt. What if 
one finds it :) ? Maybe I'll change my mind after finishing this mail.

 So, let me comment on this:
http://www.phys.lsu.edu/students/merchan/GNOME/Recommendations/Clipboard

 - Clipable Data:
  Oh well :(. Not much to add here.

 - Clipping persistance:
  I find it practically unacceptable to have the app stay around until it 
looses the selection ownership. Just imagine you have some app running with a 
huge document open, making it consume 100's of MiB RAM (and show me some app 
that actually does proper cleanup on exit, not to mention the fact that time 
I checked, malloc() wasn't very good at returning memory back to system due 
to fragmentation and so on). Moreover, the apps may be holding some global 
resource - e.g. many KDE apps use KUniqueApplication, which prevents running 
more than one instance of the app.

 Which means, all apps would have either to do a perfect cleanup (which I 
doubt for some strange reason), or they'd have to pass the clipboard contents 
to the clipboard daemon anyway. The latter option means that either the app 
will stay running for long anyway while transferring the data, or we're back 
to limiting transfer size. Or we need some other faster way of transferring 
the data.

 - Clipping History:
 Clipping history _is_ desirable. If you asked KDE users about what Klipper 
does or why they use it, they'd say it's because of the clipboard history, 
and not just the last item. But maybe the fact that we don't have problem 
with the contents disappearing on app exit plays a role here. In practice 
it's maybe that Klipper is equally often used for both things.

 If the _GNOME_SELECTION0,1,2... selections aim to be a perfect solution, 
they'll suffer from the same problem of being lost when the application 
terminates, causing holes in the history. Keeping them there brings us once 
again to the clipping persistance problem.

 Technically it should be doable I believe, timestamps in the events should 
make sure there will be no race conditions. However, do I understand it 
correctly that there should be no limit on the selections? If yes, what if I 
do 100 times ctrl+V of some large area in gnumeric? It will eat huge amounts 
of memory (as the large areas will result in large clipboard contents, 
otherwise Klipper wouldn't have a problem with it either). Even worse, what 
if I do those 100 selections in different applications? There will be no way 
how to limit the amount of memory used for it, not even a way how to find it 
out.

 - Eliminating Clipboard Managers:
 If you think claiming CLIPBOARD_MANAGER selection will make Klipper go away, 
you're wrong. This selection seems to be xclipboard-specific, at least I 
didn't find it documented anywhere. Moreover this part doesn't apply to 
Klipper anyway. Just BTW.


 Well, well. It looks like all the solutions suck, each in its own way, just 
some of them require less work to suck then others. Maybe you have a solution 
for some of the problems above I'm not aware of?

 BTW, would it be possible to limit the following mails only to the xdg list? 
The CC list seems to be a bit long, I even don't know if all of the people 
there are still interested in this, and I also don't like much the mails from 
the gnome list about postponing.

-- 
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/