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

[Scott Tringali]

Joerg Fischer wrote:

> I got it eventually.  Klipper simply sets the primary selection to the 
> last entry/string in its clipboard history.  This happens after nedit
> adjusted the selection to the new text (eg, when shifting), and since
> there can be only one primary selection, nedit loses it.  One can't
> see the new primary visually (must be hidden somewhere in klipper :-)
> but you can get it with dialog(get_selection("any")).  This is all
> triggered when klipper sees an empty primary selection - it doesn't
> intend to act like this if there is already a selection on the screen.
> With nedit, at the moment klipper starts there is no selection (ok an
> empty one) but then nedit surprises klipper by creating a new
> selection - rather clipboard, I mean.

In emacs when you deselect text, it doesn't set the selection to 
nothing, but the last thing you had selected.

This "laggy selection" makes a bit of sense - what's the use of no 
selection? - but that's not GTK and Motif operate.  It's almost like 
they treat it like a clipboard that's automatically populated, rather 
than something you can check to see whether something is or is not 
selected.  Someone in Qt-land decided "there never shall be a zero 
selection".

It's pretty simple to test, even with a single text widget.  If I select 
text, then click on another spot so there's no more visible selection, 
and then middle-click, do I paste A) nothing (Motif, GTK) or B) the 
previously-selected thing (Qt)?

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.