GNOME Bugzilla – Bug 353706
selecting text is unintuitive
Last modified: 2006-09-16 21:27:12 UTC
Currently selecting text in gtk works by selecting gaps. You have to select the gap where you want the selection to start and the gap where you want it to end. The nearest gaps are used when you accidently miss the gap and click on a letter. I always want to select glyphs. So I click on the first glyph I want selected and then drag to the last glyph. I release the mouse there. If I do this I often miss the first or last letter in the selection. Fun side note: This behaviour is consistently wrong in Gtk (I tested GtkLabel, GtkEntry and GtkTextArea), Qt, Gecko, XUL, Abiword and Windows (I tested the control panel). Sometimes I'm surprised how consistent user interfaces are. ;) Side note 2: Vte gets it right (from my basic testing), XChat and xterm always start selecting from the previous gap, not the nearest one.
We can at least make it an option to be inclusive in selection (that's what vte does)
Thinking about it, part of the problem is the cursor and the fact that to select text using mouse you are first moving the cursor (on your first button-down). And as soon as you have the cursor placed in one of the adjacent gaps, selection should start from that place. Having terminal-like cursors that stand on the letters not gaps is another option.
In the GtkEntry case it would be enough to just save the trailing parameter from the pango_layout_line_to_x and then do some MAX and MIN calculations with it. Or not?
Why not just always select the previous gap rather than the nearest (which could be the next)? This would be the left-sided gap in LTR languages and the right-sided gap in RTL languages. I think the general use case is that a selection started over a letter is intended to include that letter. Far more often than the corresponding case anyway to my mind.
I don't think the selection rules should be changed: - A selection is logically bounded by gaps, not by glyphs. This means, whether you like it or not, that starting and ending gaps _will_ be selected when you select text. The question is only _which_ gaps. - The text cursor is always positioned at a gap, and if you use Shift+arrow the selection will start at that gap. - If you click with the mouse, the text cursor will be positioned at the closest gap to where you clicked. I really think this needs to be the gap chosen. - the fact that the mouse cursor is a vertical bar indicates clearly that it is intended to be positioned between letters, not on top of them. The only alternative would be to move to a cursor-is-on-top-of-glyph model with corresponding changes to the text and mouse cursor images. I think that would be undesirable though since the cursor then would give no clear indication of where the next character would be inserted.
(In reply to comment #4) > Why not just always select the previous gap rather than the nearest (which > could be the next)? This would be the left-sided gap in LTR languages and the > right-sided gap in RTL languages. I think the general use case is that a > selection started over a letter is intended to include that letter. Far more > often than the corresponding case anyway to my mind. Then you will definitely miss the first character if you select backwards.
(In reply to comment #3) > In the GtkEntry case it would be enough to just save the trailing parameter > from the pango_layout_line_to_x and then do some MAX and MIN calculations with > it. > Or not? True, but see my cursor argument in comment #2.
As a user, I agree with Søren - I really don't see an issue about selecting from gaps. I mean, if I want to select text, I'm selecting from the start of one letter to the end of another (or visa versa if I'm selecting backward). Selecting from the middle of the text seems kind of odd.
gVim is another example (same semantics as vte; of course, it does have the terminal-style block cursor). It does feel natural to be selecting glyphs, not gaps. A thought - as displays get higher in dpi it becomes more and more strange to drag from the middle of a glyph and have the selection start from one side or the other. However sometimes selecting from gaps is the intended behaviour. Suggestion: hybrid behaviour, selecting from gaps if the mouse pointer was clicked in (or close to) a gap, selecting from glyphs if the mouse pointer was clicked in the middle of a glyph.
My personal opinion is that Benjamin is right. Although selections are bounded by gaps, it makes selecting things really hard (especially in the case of letters like Sans-style "i" and "l"). Dots are also very hard to select.
(In reply to comment #10) > My personal opinion is that Benjamin is right. Although selections are bounded > by gaps, it makes selecting things really hard (especially in the case of > letters like Sans-style "i" and "l"). Dots are also very hard to select. This is actually a good reason for doing the current gap-oriented selection: With gaps, it's easier to select the dot than without gaps. Without gaps you have to click somewhere in the width of the dot, but with gaps, you can click anywhere in the (say) left middle of the dot, or the right middle of the grapheme before it (that is most probably wider).
Maybe the behavior should be modified depending on the width of the underlying character, use near-gap behavior for small punctuation glyphs and including underlying glyph for larger glyphs.
(In reply to comment #5) > - the fact that the mouse cursor is a vertical bar indicates clearly that it is > intended to be positioned between letters, not on top of them. > Indeed, when positioning the cursor, I (try to) select a gap. But this behaviour is different from selecting text. That is why I never have problems positioning the cursor correctly. But when selecting text, I select text, not gaps. A very important thing is that I have no clue where a gap ends or where it starts. There are some letters (like "h" or "r") where the middle is not where I'd intuitively expect it. So in that sense it's much simpler to target a glyph then to target a gap.
I have to agree with Søren and Simon. Selecting from the gaps makes more sense to me. I tend to have have trouble selecting text in the terminal, because it wants to be a character based selection rather than gap based.
I agree with Soeren, and I don't see any reason to deviate from what the majority of environments do
(In reply to comment #13) > Indeed, when positioning the cursor, I (try to) select a gap. But this > behaviour is different from selecting text. That is why I never have problems > positioning the cursor correctly. But when selecting text, I select text, not > gaps. I agree with Benjamin Otte here: selecting text or positioning an (insert) cursor is not the same. When positioning a cursor in overwrite mode, I would expect the cursor to be over or before the glyph I clicked (so that entering a character would overwrite the glyph clicked on). When selecting text, I expect the glyphs I click the mouse button on to be selected, as well as the glyph I unpress the mouse button on. When I position an insert cursor, I want it to go to the nearest position between glyphs (the nearest "gap"). Some Windows programs try to solve this problem by always selecting whole words (because in practice this problem often shows up when you try to select a word or a group of words), but IMHO that only moves the problem to other situations (where you don't want to select a complete word, those programs almost force you to do, which is maybe even more anoying).