Clipboard selection - solution(?)

Thu Nov 14 17:37:44 GMT 2002

 Hello,

 mystery solved, I think what to do with the damned selection, halelujah :) !

 Ok, let's first repeat some things:

 The style used by e.g. Gtk+ or xterm, which I called X11-pure, is like this:

  Selection is selected text, and selected text is selection (the ONLY 
 selection). Which means:
 - selected text, no matter how selected, will be pasted by MMB
 - if there's nothing selected, MMB won't do anything
 - if you select something in one app, previous selected text is unselected,
   no matter where it was, even in other app (this a bit conflicts
   with the 'if you don't know about MMB, it won't get in your way at all'
   claiming)

 This has several annoying consequences:

 - when tabbing or opening a dialog preselects, this changes
   PRIMARY(=selection), on the other hand preselecting is often handy
 - stricly speaking, 'Copy link location' shouldn't set PRIMARY, as the URL
   cannot become highlighted
 - selecting something unselects the previously selected thing - this may seem
   to be only a small problem, but see below

 The differences from the X11-pure style can be:

 1) text selected by keyboard doesn't become PRIMARY
 2) autoselected text (tabbing, preselecting) doesn't become PRIMARY
 3) when there's no selected text, selection is still remembered (the last
     valid selection)
 4) when a text is selected elsewhere, previously selected text stays selected
 5) when a text is selected elsewhere, previously selected text stays selected
     with a different color
 6) explicit actions like 'copy link location' set selection, even if there's
    no text selected

 Now, let's have a look at the problems and solution one by one.

 First, the easy ones:

 1) No, keyboard changes should set PRIMARY too - no special reason, besides
    'why not?'.
 3) Yes. This is convenient and there's no special reason against. X11-pure
     style users simply won't try MMB when they see no selection, so they
     won't find out ;).
 6) Yes. This is often used. X11-pure style users either won't use such menu
     entries, or they won't see any selection, so they won't MMB ;).

 Finally, the more complicated ones, i.e. 2),4),5). They are actually all 
related, because 4) and 5) contradict each other, and 2) needs either 4) or 
5). It needs them for two simple reasons:
 - select something, then open a dialog, which will preselect, but will not
    set PRIMARY. Now, if there must be only one selected text, the previous
    one has to become unselected. The only reliable way of telling the old
    selected text to become unselected is by taking PRIMARY, which a bit
    conflicts with the intention of not affecting PRIMARY, right ;) ?
   As I can see it, if we want 2) (and we want it, right?), then there must be
   allowed more than one selected text at the same time.
 - start KWord (OpenOffice writer, whatever), type something, select part of
    it, right click and select one of the entries which opens a dialog, e.g.
    the one changing font. Now find a lineedit there (e.g. the color change
    dialog has a couple of them), and select the text in it, then simply
    change some settings in the dialog, and confirm. The dialog closes, and
    now guess what? The changes have been applied, and you see the selected
    text changed. What's so strange about it? Well, if KWord (OO writer,
    whatever) used the X11-pure style, the result could vary from a crash to
    the same behaviour like now, with the text becoming unselected and no
    change applied being the most probable case.
   This is actually very similar to the QTextEdit::cut() issue that started
   all this (in fact, solving this means that the reversed
   clipboard->selection syncing could become "legal" again). The bad thing
   here is simply that the selection changes out of sudden, which
   - confuses the user ('why the hell does it get _sometimes_ unselected?')
   - the programmer needs to take care of it - for example, to get the current
     behaviour, the code should still remember the selected text even after
     losing PRIMARY, it should apply the changes to it, and it should then
     select it again (words like *CENSORED* or *CENSORED* or *CENSORED*
     describe it even better)

 A possible alternative to 2) could be no autoselecting at all, as suggested 
in bugreport http://bugs.kde.org/show_bug.cgi?id=50471 , but that would be 
trading one annoying thing for another, and it wouldn't solve the KWord case 
anyway.

 So this means 2) should be 'yes', and either 4) or 5) should be 'yes'. Also, 
note in GNOME HIG (usability guidelines 
http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-entry 
that the section describing lineedits says that autoselecting shouldn't 
change PRIMARY. Looks like GNOME coders and GNOME HIG somewhat disagree here. 
But it's good to know this detail :).

 BTW, before it, I think I've found out how the autoselecting/autodeselecting 
works (in Qt, and possibly the same in MS Windows, but I couldn't find a 
single dialog with a textedit). The only thing that autoselects are lineedits 
and widgets using them (spinbox, editable combobox). They are also the only 
thing that autodeselects on focus-out-to-another-widget (in MS Windows it's 
actually that they don't show the selection when they don't have the focus,
but they still remember it - not that it makes much difference). Other widgets 
don't  autoselect, they don't autodeselect. When you have e.g. two textedits 
in one dialog, and you select in both, this makes it hard to say which of 
them has focus, but I personally don't consider it worth bothering. I don't 
mind if this thing stays the way it is.

 The remaining problem, 4) or 5) :

 4)  This one has the nice advantages of being simple for everybody (including
     the programmer). Well, besides those X11-pure style people claiming they
     won't know which of the selected texts MMB will paste. I personally don't
     consider this to be a big problem. Matthias Ettrich said that MMB pasting
     is actually more like DND than a clipboard. I agree, one usually selects
    something with the mouse and MMB pastes it somewhere else within several
    seconds (so there shouldn't be big trouble with remembering what MMB will
    paste >;)  ). Moreover it should be rather rare to see several selections
    at the same time in one window or in several equally "important" windows
    (e.g. not KWord main window vs the font dialog - there it's obvious which
    one would get pasted). In fact, I don't remember anybody here complaining
   about this, only on gtk-devel-list@  where Havoc posted a link to this
   discussion. On the other hand, our habbits are somewhat influenced by our
   clipboard usage history, and e.g. I myself run one maximized app per
   virtual desktop, so I definitely wouldn't have this problem.

 5)  The idea here is that the one selected text that would be pasted by MMB
    would have the normal color, the other selections would be e.g. a bit
    brighter. Try some Gtk+1 application, Mozilla also has two different
   colors when showing a page, but it changes it on focus out. X11-pure style
   users will be happy, but it is slightly more complicated for the programmer
   and confusing for unaware users ('huh, why is it suddenly light blue?' -
   even my first reaction after seeing it in gqview was 'huh?', even though
   I quickly realized what it is).
     Gtk+2 doesn't have this feature anymore, it simply unselects. This is
   because in Gtk+2, the selection color is different for focused and
   unfocused lineedit (when there's something selected in two lineedits, it
   would be hard to say which of them has focus - Gtk lineedits don't
   unselect on focus out). Changing color also for will/won't be pasted by
   MMB would mean 4 colors.
     From programmers point of view, this means every widget able to have
   selected text would need extra bool flag meaning
    this-will-be-pasted-by-MMB, and the selection color would depend on it.
    When selected using a mouse or keyboard, it would change PRIMARY and set
    this flag to true, when autoselecting, it would change the flag to false.
    When losing PRIMARY, it would not unselect, but change the flag to false
    and repaint (BTW, IMHO Ctrl+C should always copy the selected text, no
    matter if selected manually or automatically).

 I'd suggest going with 4), unless there would be many people complaining, in 
which case I'd prefer having one option for switching between 4) and 5), 
defaulting to 4). Technically, the option wouldn't be much different from 5) 
- there would be let's say QColor QClipboard::nonPrimarySelectionColor( 
QColor ), which would use either QColor::light() or return what it got, 
depending on the option. Not having the option would save one 'if' in this 
function, and one checkbox in qtconfig.

 To sum it up:

 There's no official X11 spec saying how PRIMARY should work from the users 
point of view (correct me if I'm wrong here). Any mix of 1),2),3),4),5),6) 
would be still compliant with the X11 specs, since they only describe the 
underlying mechanism, and that would stay the same. There are only various 
interpretations of how it should work, and the ways it's done in various 
apps, but they're usually inconsistent with each other. The X11-pure style, 
as shown above, has some flaws. The suggested solution, as far as I can say, 
almost doesn't affect X11-pure style users, only in very minor ways, and 
avoids the problems. Which means, I don't see a good reason why we couldn't 
simply do it as I suggest.

 The suggested solutions are 2),3),4),6) or 2),3),6) and an option for either 
4) or 5), defaulting to 4). Using 2),3),5),6) is acceptable too.

 If you say this is ok, I'll take care of Qt patches and making TT to apply 
them (I'm already a good friend with QClipboard anyway, maybe I could make 
these changes slip in with the big patch I already have >;) ). At least I 
hope, QLineEdit is far more complicated that I expected.

 I'd like also post somewhere few rules about coding clipboard related things 
(like saying that QClipboard::dataChanged() is currently somewhat unreliable, 
but it should get better soon, or saying that calling QClipboard::pixmap() in 
a slot connected to dataChanged() is a bad bad thing, when the only thing you 
want is enabling/disabling the Paste menu entry).
 What's the policy for putting things at developer.kde.org?

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