OT: klipper's misbeliefs [was: NEdit & KDE loss of selection problems]

[Joerg Fischer]

Scott Tringali wrote:

> Qt has this laggy selection, so it's no surprise that KDE follows it.  I 
> presume this button is to make GTK apps behave more like Qt apps.

There is a difference with klipper, though.  The user needn't focus /
interact with klipper!  He can click on klipper's panel symbol to make
it pop up and then click on an entry of its history, so klipper sets
the primary selection to this string.  This is ok.

However, klipper does also change the primary selection from behind
the back, if the "prevent empty clipboard (ie, selection)" is on.  One
might belief that this would also be ok.  If the selection is empty,
no harm is done in the X client the user currently is working in. 

But, and this is where it all fails, no one can predict when the next
selection will be.  Selections are transient - they just come and go
(even more so for X, where there is only one primary system-wide).

If you have really quick fingers you might get the same effect by
manually changing the selection in gedit (selection goes away, klipper
sees empty selection and starts because everything seems fine, gedit
has all of a sudden a new selection, and just after that slow klipper
sets the primary while there is already one), but I doubt so.  NEdit
is just faster (we all know this), and is fully macro programmable (so
btw nedit on its own can't know if a macro deselects and reselects
directly thereafter - just in case you consider to somehow detect
whether or not to disown empty selections - this just boils down to
either disowning or keeping them in all cases).

Cheers,
Jörg