From kde-usability Sat Mar 20 17:11:55 2004 From: Leo Savernik Date: Sat, 20 Mar 2004 17:11:55 +0000 To: kde-usability Subject: Re: standardizing modes of text selection Message-Id: <200403201811.56853.l.savernik () aon ! at> X-MARC-Message: https://marc.info/?l=kde-usability&m=107980265531632 -----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. > [...] > 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