Opened 14 years ago

Closed 14 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:
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 by axeld, 14 years ago

Owner: changed from axeld to jackburton

comment:2 by diver, 14 years ago

Cc: diver added

comment:3 by jackburton, 14 years ago

Status: newassigned

comment:4 by jackburton, 14 years ago

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

comment:5 by jackburton, 14 years ago

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

in reply to:  5 ; comment:6 by kirilla, 14 years ago

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.

in reply to:  6 comment:7 by jackburton, 14 years ago

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 by jackburton, 14 years ago

Component: GeneralUser Interface/InterfaceKit
Priority: lownormal

comment:9 by jackburton, 14 years ago

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

comment:10 by jackburton, 14 years ago

Resolution: fixed
Status: assignedclosed

Got finally fixed in hrev18956

Note: See TracTickets for help on using tickets.