From kde-usability Sat Mar 20 15:17:01 2004 From: "Jamethiel Knorth" Date: Sat, 20 Mar 2004 15:17:01 +0000 To: kde-usability Subject: Re: standardizing modes of text selection Message-Id: X-MARC-Message: https://marc.info/?l=kde-usability&m=107979583230761 >From: Leo Savernik >Date: Sat, 20 Mar 2004 14:12:10 +0100 > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Am Samstag 20 März 2004 06:36 schrieb Jamethiel Knorth: > > Okay, I know not everything was agreed on here, but do we all at least > > agree that the standard for selection in KDE should be: > > > > Single-Click - No selection > > > > Single-Click & Drag - Select from cursor, by letter > > > > Double-Click - Select word > > > > Double Click & Drag - Select word and select by word, selecting to the > > beginning and end of any word the cursor moves onto. > > > > Triple -Click - Select row > > > > Triple-Click & Drag - Select row and select by row, selecting to > > (inclusively) any line the cursor is dragged over. > >Very concise, well done summary. > > > > Reversing Cursor Dragging - Select in the same manner as before, >changing > > the end point but never the start-point of the selection (specifically, >not > > like the keyboard text-selection in apple where it expands in both > > directions) > >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. 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. 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. This means that holding shift while clicking with the mouse will always expand the selection, unless the click occurs inside the current selection, in which case the selection will be shortened from the end closest to the mouse click. If this behavior were added, the following would need to be added to my list above: - Shift+Click: Expand selection to click location from point nearest to click location, if the click occurs outside the selection area. If click occurs inside the selection area, reduce selection to click location from the selection endpoint nearest to the click location. This then poses two new questions: 1) Is the reduction occuring from the end nearest to the click, or does it just reset that endpoint in relation to the original start-point of the selection, so that the first place you click is always the center of that selection? 2) Does the selection expansion with shift+click occur in the same manner as original selection did, or does it expand according to its own click-rate (single, double, triple)? To #1 I would say keep the original startpoint for the selection, but I am very uncertain. To #2 I would say that it would just expand in the manner the original selection did, in which I would need to append, "The selection always expands and contracts according to the manner (by letter, word, or line) in which it was originally created," to the end of my Shift+Click explanation. 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? 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. That would mean that double-clicking one word would select that word and then ctrl+single-clicking elsewhere would also select a whole word, despite only being a ctrl+single-click. That might be described as: - Ctrl+[mouse-action]: Retain old selection(s). If the mouse-action would create a selection, that selection remains of the same expansion-type as the original selection. All selections must be of the same expansion-type at all times. 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. Otherwise, treat as a normal mouse action. This then also poses a few other problems. What happens in the case of keyboard expansion on mouse-selections? I think that they should transparently add to one another. (This only applies in thing that allow keyboard-selections, such as editors) I would say that, whenever the mouse is used to expand a selection, the cursor is move to the point at the end of the selection expansion if it was expanded from nothing or from the end, or the beginning if expanded from the beginning (not always where the click occurs). If a keyboard is used to move the cursor while holding shift, this edits the current selection. If it moves over an unselected area, that is added to the selection. If it move over a selected area, that is removed from the selection. 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: - 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. - 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. This then poses the further question of what happens with generic selection overlap. Is the result just always inversion? Consider: I click+drag and select thirty words. I Ctrl+click+drag, at the end crossing over part of my original selection. The easiest answer to logically reason out is that any overlap results in selection inversion. That only needs this comment: - In the case that this is not covered by any previous rules, if an action would cause a selection where there is already another selection, this instead results in the overlapping area to be deselected. This has the nice feature that once could triple-click to select a bunch of lines, then ctrl+double-click to remove some words from the middle. However, it also causes an interesting problem. It makes it somewhat awkward when double-clicking and dragging to select a bunch of words, the ctrl-triple clicking below and dragging up. It seems fairly natural to have the larger level selection encompass the smaller. However, I do not see a good way to make a consistent rule of it, so I would avoid it. I think that the only remaining issue (yes, there is another issue) is what to do with programs which do not support multiple selections. Does ctrl+click/mouse-motion result in deselection, or does it allow free mouse motion without deselection? I would say that it would allow free cursor motion. As it turns out, I was wrong. There are still more issues to consider. What happens with typing to replace when multiple selections are present? What happens with typing when the cursor is not at the selection? I would say that the action of hitting ctrl+[anything-which-causes-motion] results in the current selection becoming an old selection, and old selections never get replaced by typing. That would need this addition: - In the result of cursor motion without alteration of the current selection, whether it be by creating a separate selection or by moving the cursor without creating or destroying any selections, the current selection becomes an old selection. - Old selections are not replaced by typing. In the event of anything which would replace or deselect the current selection, old selections are deselected without any effect to them. The only instance in which old selections are edited is by exterior commands (cut, copy, indent). In the case of exterior commands which replace a selection (paste) they only replace the current selection, not old selections. Wow, this gets really damn complex when you try to deal with every situation! Okay, just one more thought. Wouldn't that last behavior I mentioned be confusing when two separate selections butt up against one-another perfectly? They would appear as one selection, but actually be two. Could this be solved by changing the selection color for old selection slightly, or would that just be more confusing? Despite how complex all that seems, I think it is actually fairly straightforward. > > > > If we are in agreement, why doesn't whoever originally suggested this >(was > > that you Leo?) write it up all pretty-like (with a notice that selection > > modes for URLs is not yet defined) and send it off to the relevant >parties. > > If we could get this to be the official KDE standard, that'd be great. > >Good point. > > > > As to who are relevant parties, I don't know. KDE-Policies? > > FreeDesktop.org? OpenUsability.org? > >fdo doesn't seem to be the right place for such submissions. I also think >this >is no usability issue, but a style issue. I consider a place like >http://developer.kde.org/documentation/standards/kde/style/basics/ >to be most appropriate. I think this is definitely a usability issue. Usability is screwed over by inconsist and unpredictable behaviors, and this is currently such a behavior. > > >[...] > >mfg > Leo _________________________________________________________________ Get tax tips, tools and access to IRS forms – all in one place at MSN Money! http://moneycentral.msn.com/tax/home.asp _______________________________________________ kde-usability mailing list kde-usability@kde.org https://mail.kde.org/mailman/listinfo/kde-usability