Clipboard selection - solution(?)

[Owen Taylor]

I think there is a clear standard interpretation of how
PRIMARY should work currently .. what you call "X11-pure";
what Xt, GTK+, Java/Swing, etc do.

I'm not totally opposed to changing this, but if it is
changed, then we have to make sure that we have a 
easy-to-understand definition of exactly how things
should work. 


Lubos Lunak <l.lunak at suse.cz> writes:

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

[...]

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

Possible confusing thing here is that if you you close the window where
text was selected, PRIMARY might be lost. If you close the application,
PRIAMRY will be lost (unless a clipboard manager intervenes)

>  4) when a text is selected elsewhere, previously selected text stays 
>     selected

It is important to understand that this change of the "X11-pure" model
by itself, isn't workable. It only works when accompanied by
widgets unselecting on focus out to a different widget within the
toplevel; otherwise you would get a confusing visual mess of multiple 
widgets selected within every toplevel.

>  5) when a text is selected elsewhere, previously selected text stays selected
>      with a different color

I have to disapprove of this because:

 - It's a real killer for cross-platform toolkits to do correctly
   since it is a completely new concept.
 - It exposes the concept of "primary selection" in an obvious and
   strange way to unaware users.
 - As you note, it gets unmanageable when you use different colors
   for unfocused and inactive selections.

>  6) explicit actions like 'copy link location' set selection, even if there's
>     no text selected

If I understand what you are actually, proposing, I think viewing
it as a modification of the "X11-pure" model is a mistake.

The simplicity of the X11-pure model is in the simple statement:

 - Middle-mouse-button pastes the currently selected text.

As soon as you break this, and 2), 3), 4), 6) all break this,
then you have a completely different model.


I think the simple model that corresponds best to what you 
are proposing is
  
 Middle-mouse-button implements a "short-cut paste" that pastes 
 the most recent of:

  - text selected explicitely by the user with the mouse or keyboard
  - text cut to the clipboard
    
    [ Yes, this isn't done currently, but it's the only way
      I see of putting 6) into any consistent framework ]

Then you would need to combine this model with some 
PRIMARY-selection-independent model of how selections should 
work in widgets.

Regards,
                                        Owen 

=========

Appendix: Couple of comments about your mail not relevant
 to my main point.

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

Note that in OOWriter, Microsoft Wordpad, IE, etc, there is 
actually special handling of the "main area" of the application 
window. For example, when you focus an element on the toolbar, 
selection isn't removed from the main area.
 
>  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.

The HIG writers sometimes don't pay as much attention to what 
GTK+ actually does as they should.

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

In MS Windows, text areas deselect on focus out. You have to try a
bit though to discover this ... creating a web page with multiple
textarea elements and viewing it in Internet explorer is a easy way 
to experiment.