[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Clipboard daemon
- From: Lubos Lunak <l lunak suse cz>
- To: xdg-list freedesktop org
- Cc: Murray Cumming Comneon com, merchan baton phys lsu edu, h lai chello nl, desktop-devel-list gnome org, carpdjih mailbox zrz tu-berlin de, jody gnome org
- Subject: Re: Clipboard daemon
- Date: Thu, 18 Dec 2003 15:59:12 +0100
On Saturday 13 of December 2003 19:26, Murray Cumming 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.
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
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:
- 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
- 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
- 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.
SuSE CR, s.r.o. e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
[Date Prev][Date Next] [Thread Prev][Thread Next]