Opened 13 years ago

Closed 13 years ago

#494 closed bug (fixed)

Arrow key behaviour on selected text

Reported by: jonas@… Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version:
Keywords: Cc: diver
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

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.

Change History (10)

comment:1 Changed 13 years ago by axeld

Owner: changed from axeld to jackburton

comment:2 Changed 13 years ago by diver

Cc: diver added

comment:3 Changed 13 years ago by jackburton

Status: newassigned

comment:4 Changed 13 years ago by jackburton

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

comment:5 Changed 13 years ago by jackburton

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

comment:6 in reply to:  5 ; Changed 13 years ago by kirilla

Platform: All

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.

comment:7 in reply to:  6 Changed 13 years ago by jackburton

Description: modified (diff)

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.

comment:8 Changed 13 years ago by jackburton

Component: GeneralUser Interface/InterfaceKit
Priority: lownormal

comment:9 Changed 13 years ago by jackburton

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

comment:10 Changed 13 years ago by jackburton

Resolution: fixed
Status: assignedclosed

Got finally fixed in hrev18956

Note: See TracTickets for help on using tickets.