[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: standardizing modes of text selection
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2004-03-20 17:11:55
Message-ID: 200403201811.56853.l.savernik () aon ! at
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag 20 März 2004 16:17 schrieb Jamethiel Knorth:
[...]
> >Let's make an explicit distinction here: Mouse selection *will* expand to
> >the
> >beginning *and* end of the word/line when issued, but keyboard selection
> >will
> >*not*.
>
> I think that you misunderstood. Perhaps you have never seen the
> text-selection in BBedit or one of the other old Mac editors:
>
> If I hit shift and the left arrow, the selection will expand left. If,
> while still holding shift, I hit the right arrow, the selection will expand
> right from the right edge. It will not shrink from the left, where my
> cursor currently is.

Waah! I know this behaviour from Mathematica. It drives me nuts!
>
> As an illustration, if my cursor were in the above text, say after the 'd'
> in 'expand', and I were to hold shift and hit left five times, 'xpand'
> would be selected. If I were to then, while holding shift, hit right four
> times, 'xpand lef' would be selected, rather than just 'd'. The cursor
> motion only expands the selection, never shrinks it.
>
> What I was saying is that we do not want that behavior.

Fully, fully, totally agreed.
>
> However, it makes one more question occur to me. If I shift-click, click,
> click, what happens? In Safari (I'm on a Mac right now) if I hit shift,
> then click somewhere, it expands from the current selection to that point.
> Then, if I shift click again, the selection will expand to that point from
> the end nearest to it. 

I originally implemented this behaviour for khtml, but I noticed that
- - it sucked.
- - no other app (Mozilla, OpenOffice.org, KWord, ...) did it like that.

[...]
> If this behavior were added, the following would need to be added to my
> list above:

This is not what I had in mind. See annotations:
>
> - Shift+Click: Expand selection to click location from 
end point of selection
> location. <snipped>
>
[...]
> This then also means that the text selection expansion with Ctrl+Click
> requires explanation. The standard behavior is to have a new selection be
> started without the removal of the first if Ctrl+Any-Selection-Action is
> hit. The question is, what sort of selection is that new selection?

Multiple selections are beyond the scope of my proposal. Let's get single 
selections right first ;-)
>
> Does the new selection occur in the same manner as the old one? My answer
> would be no. Then, if you double-click and drag, selecting a bunch of
> words, then ctrl-triple-click and drag somewhere else, that second
> selection selects by lines, not words. That would in this addition to the
> selection recommendation:
>
> - Ctrl+[mouse-action]: Retain old selection(s). Otherwise treat as a normal
> mouse actions. If the mouse action would create a selection, create that
> selection in addition to old selections. In the case of further mouse
> action which would not remove the current selection but do not contain a
> Ctrl, still do not remove the previous selection(s).  In the case of
> further mouse action which would remove the current selection, also remove
> all old selections.
>
> However, it would be reasonable to select in the same manner as the
> original selection. 
[...]

This is no good because then the user would be confined to the principal 
selection mode for all further selections.

[...]
>
> Also, then, how does the keyboard expand the selection? Does the keyboard
> expand the selection in the form of the selection, or just
> letter-by-letter? I would say letter-by-letter, unless holding ctrl (I
> think that is the key for expanding for word, at least by default). The
> reason is that doing otherwise would make selection extremely irregular
> when selecting by line (If I hit left, it grabs a line upwards?). That
> would mean adding this explanation:

Yes
>
> - Keyboard-Input: In an editor, input which adds text of any sort replaces
> the text (with rare exceptions, such as indent by tab in many editor). In a
> view-only application, such input does not affect the selection.

Certainly it does. Have you ever seen caret mode in khtml? Or the kate 
readonly part?
The point is this: If there is a caret, it will affect the selection. If there 
is none, it won't.
>
> - Keyboard-Motion: Removes the selection and moves the cursor.
>
> - Shift+Keyboard-Motion: The selection expands or contracts to where the
> cursor moves to, moving in the manner that the keyboard dictates the cursor
> move. In simple, anywhere the cursor crosses which is selected becomes
> unselected. Anywhere the cursor crosses which isn't selected become
> selected.
>
> Then comes the question of Ctrl+Keyboard Motion. In a few occurances,
> holding ctrl allows cursor motion without loss of selection (I can't think
> what off-hand, but I have seen it in things which allow
> multiple-selections). Does Ctrl+Keyboard Motion then just allow cursor
> motion without selection loss, and Shift+Keyboard motion just allow
> expansion of the selection? If so, all that needs adding is:
>
> - Ctrl+Keyboard-Motion: Moves the cursor without removing any selections.

No, Ctrl+cursor_keys will always move word by word (With Shift: extend 
selection)
>
[...]
> Wow, this gets really damn complex when you try to deal with every
> situation!

Indeed. This is way off what I had in mind first. However, when (if) I write a 
spec, I'll use your thought as a basis.
>
[...]

mfg
	Leo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAXHtbj5jssenUYTsRAl0XAJ9QC89l0nmGXfibe2j8O21L5T1YzQCgpEX5
OSqazSDTq0W6dZKinbIkZKE=
=0eqq
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]