Clipboard problems (yes, again)

[Lubos Lunak]

 Hello,

 I propose doing the following changes in KClipboard:

- making completely separate clipboard and selection the default setting

 I insist on this one. See http://bugs.kde.org/show_bug.cgi?id=48024 . Quite 
easy to reproduce, just find some QTextEdit in any KDE app, make sure your 
Klipper is _not_ configured to have clipboard and selection completely 
separate, select some text in it using mouse, wait two seconds, press Ctrl+X.

 The fix for this specific problem is easy, just moving the call to 
removeSelectedText() above the clipboard setting in QTextEdit::cut(). 
Everybody who knows why, two bonus points; the rest - better don't try to 
find out, you'll risk headache. However, this is the third time (IIRC) this 
syncing behaviour is causing trouble, and more are likely to come (yes, 
they're Qt bugs, but nevertheless, they're bugs - and as you can see in this 
QTextEdit case, they're hideous. In fact I'm even hesitant to send the change 
to TT). Also remember that all of these three problems lasted for quite some 
time, before somebody finally found out a way how to reproduce them, showed 
it to me and I hunted the bug down. Making the default the way it was 
intented to work with X11 should take care of possible problems with KDE3.1.

- completely nuking the 'implicit selection' feature, called 'When the 
clipboard is set, set the selection as well' in Klipper, as it simply doesn't 
make any sense to me

 Really, I don't see the purpose of this. If I'm going to put some text in 
clipboard, I will usually have to select it first using the mouse, i.e. it 
goes in selection anyway, so why setting it explicitly? Unless somebody has a 
good explanation why this mode is useful, I'd really like to see it gone.

- completely nuking the 'synchronizing' feature

 (I'd really like to, really). I' afraid there would be enough people willing 
to have this, no matter how many things this would break, so I don't think 
you'd let me. Still, at least for the record, could somebody explain why this 
is actually useful, and why does it have to be two-way and not only 
selection->clipboard?


 In fact we'd probably need some document explaining how the 
clipboard/selection are supposed to work. E.g. according to ICCCM[1] there's 
only THE selection, one and only - in other words, if you select something in 
one app, it should be the only selected thing in the whole session, the app 
with previously selected text should deselect. Yet this doesn't always 
happen, and also often selecting using shift+arrows does set the selection, 
even though there is something selected. This is inconsistent, and moreover 
it's pretty annoying (the deselecting, that is).

 It'd be probably good also to agree on some interpretation with other (Gtk+ 
etc.) people and update the description text at [2]. Having more apps 
supporting some reasonable behaviour could also help with some Klipper 
related problems (like when working with Emacs and having large selected 
text).

 Feel free to comment. But before you do, I ask you to read at least [2]. 
There are simply some things that can't be done with X, and there's no point 
in discussing what-if scenarios. I'd also like to explicitly point out that 
selection and clipboard are usually considered to be orthogonal (well, 
besides those people who got too much used to the broken Qt2 behaviour). I'd 
also appreciate if you answered my questions before you start to argue.

[1] - ICCCM - section 2 -  http://tronche.com/gui/x/icccm/sec-2.html#s-2
[2] - http://www.freedesktop.org/standards/clipboards.txt

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