Arrow key behaviour on selected text

[jonas@…]

In Haiku, when renaming files in Tracker, or editing text in StyledEdit, the arrow keys don't behave as in BeOS when you've got a text selection.

Pushing the left arrow key should unselect and move the cursor to the left edge of the previously selected text. The right arrow key should move the cursor to the right edge of the selected text.

Windows and MacOS [used to?] have opposite behaviour in this area. BeOS does it the MacOS way. Haiku's behaviour looks incomplete. It looks like it simply moves the last known cursor position once, left or right.

BTextView/BTextControl are likely places to look in.

[jackburton]

Should be improved a bit in hrev18462, although not fixed yet

[jackburton]

Can you check again what beos does and if our implementation is correct in that regard ?

[kirilla]

It's not yet correct. There are multiple ways to select text, which makes the cursor end up at the end, at the beginning, or somewhere in the selection, but the behaviour of arrow-left/right on selected text should be the same, regardless.

You can see how the arrow keys are supposed to work when editing filenames in Tracker on BeOS. (Click filename, press arrow left or right.)

StyledEdit Scenario: You have a block of text with a subset of it currently selected. Maybe it's easier to think of it as a text consisting of three words, the middle word currently selected. Now, if you press Left-Arrow in BeOS (or in MacOS) the cursor is moved to the left side of the word, and the word is no longer selected. The Right-Arrow key would have moved the cursor to the right side of the word. Windows is similar, except the behaviour of the two arrow keys is opposite to that of MacOS/BeOS. Haiku currently simply uses the last cursor position and moves 1 character left or right, which is non-standard. In the current implementation it seems that when you have selected a word by double-clicking it, the cursor is *somewhere in the selection*, and there's no visual clue to where it is. I think that conceptually the entire selection -is- the cursor, and should be, and that this is the key to understanding why MacOS/BeOS work the way they do, (which is deselecting and having the cursor appear at the beginning or end of the deselected text). Entering some text instead would replace the selection. This too supports the selection as -being- the cursor.

Why Windows is backwards, I don't know. A legacy from some older system, probably.

[jackburton]

You can see how the arrow keys are supposed to work when editing filenames in Tracker on BeOS. (Click filename, press arrow left or right.)

I can't check on BeOS, that's why I asked you to do that :). Thanks for the description, though, I think that's enough to be able to implement the selection correctly.

[jackburton]

I think we're getting there, aren't we ? Are there still differencies between hrev5 and our implementation ?

[jackburton]

Got finally fixed in hrev18956