Menubar navigation bugs

[hma]

Menubar navigation bugs in revision 24105

If the menubar widget behavior is work in progress, these are mostly unnecessary to report, but here goes. If nothing else, these may be useful as a check list. I have to also comment that I was really pleased when Haiku's menus started to open when hovered over instead of clicking each one open separately. Great work.

Click a menu open (e.g. Edit) and leave the cursor on top of the menu. Now press arrow-key-left or arrow-key-right. This should open the neighboring menu on left or right. It looks like it tries to do that, but seems like the hovering cursor prevents it.

Click a menu open and leave the cursor where it is. Now press arrow-key-down. The first item on the menu should get focus, but the focus goes directly to the second item. Same happens with sub-menus.

Click a menu open and leave the cursor where it is. Pressing esc-key should close the menu, but it doesn't.

Open a menu and leave the cursor anywhere on the opened menu. Using arrow keys to navigate should work but it doesn't.

Open a menu that has sub-menus e.g., Terminal Settings menu, Use arrow keys to move focus to Window Size. A sub-menu should open automatically but it doesn't. Pressing arrow-key-left opens the menu, but needing a key press to open a sub-menu is inconsistent with how mouse navigation works.

Automatically opening or not opening sub-menus could be a convention decision, but Haiku's Deskbar design requires automatically opening sub-menus. Otherwise keyboard navigating Deskbar becomes confusing (if sub-menus are opened with arrow-key-right, but Desbar sub-menus open to the left side of the menu).

Open a menu and use arrow keys to navigate into a sub-menu. It is not possible to get out of the sub-menu using only arrow keys (arrow-key-right should move to the sub-menu and arrow-key-left should move back to the parent menu).

Open a menu that has a sub-menu and that is not the last menu on the menubar e.g., StyleEdit Font menu. Use arrow-keys to navigate into the sub-menu. Pressing arrow-key-left in the deepest sub-menu should move the focus to the next menu on on the menubar. E.g., in StyleEdit, when focus is on Font menu's Color sub-menu and user presses arrow-key-left, the Document menu should open.

[jackburton]

I'll have a look, but I'd like to apply the patch attached in bug #284 first.

[jackburton]

Changed a bit the description, since that part was already fixed and tracked in another ticket (can't find the number right now, sorry). For the keyboard navigation behaviour, bugs apart, this should be more or less how beos worked. We can change that if it doesn't work well for most people though. Let's discuss this.

[Ziusudra]

Replying to hma:

Click a menu open (e.g. Edit) and leave the cursor on top of the menu. Now press arrow-key-left or arrow-key-right. This should open the neighboring menu on left or right. It looks like it tries to do that, but seems like the hovering cursor prevents it.

Click a menu open and leave the cursor where it is. Now press arrow-key-down. The first item on the menu should get focus, but the focus goes directly to the second item. Same happens with sub-menus.

These two no longer happen.

Click a menu open and leave the cursor where it is. Pressing esc-key should close the menu, but it doesn't.

While the menu does close now, there are still issues with escape. See #4594 and #4292

Open a menu and leave the cursor anywhere on the opened menu. Using arrow keys to navigate should work but it doesn't.

No longer happens. Although, if you use the keyboard to navigate to another menu and then click the mouse button, the menu option that was under the mouse pointer will be activated, even though it is now not under the pointer. Created #6291

Open a menu that has sub-menus e.g., Terminal Settings menu, Use arrow keys to move focus to Window Size. A sub-menu should open automatically but it doesn't. Pressing arrow-key-left opens the menu, but needing a key press to open a sub-menu is inconsistent with how mouse navigation works.

Automatically opening or not opening sub-menus could be a convention decision, but Haiku's Deskbar design requires automatically opening sub-menus. Otherwise keyboard navigating Deskbar becomes confusing (if sub-menus are opened with arrow-key-right, but Desbar sub-menus open to the left side of the menu).

I don't know about these two. If not automatically opening sub-menus, the sub-menu indicator would have to be changed to point left and maybe be on the left side of the menu. So, it would have to be known to which side the sub-menu will open when the super-menu is displayed.

It should be possible to automatically display the sub-menu and leave the selection at the super item. But, I don't think that at this point pressing a key can abort a submenu; either that would be needed or a delay before displaying the sub-menu. If the sub-menu opened to the left that would change which key would be used to get to it.

Either way it would be considerable work to change something that I think works well now.

Open a menu and use arrow keys to navigate into a sub-menu. It is not possible to get out of the sub-menu using only arrow keys (arrow-key-right should move to the sub-menu and arrow-key-left should move back to the parent menu).

This was fixed, see #5996.

Open a menu that has a sub-menu and that is not the last menu on the menubar e.g., StyleEdit Font menu. Use arrow-keys to navigate into the sub-menu. Pressing arrow-key-left in the deepest sub-menu should move the focus to the next menu on on the menubar. E.g., in StyleEdit, when focus is on Font menu's Color sub-menu and user presses arrow-key-left, the Document menu should open.

At first I didn't agree, but then I noticed that if you actually go into the Font menu you can't get to the Document menu unless you first go to the Edit menu. (Since all of the Font menu's items have sub-menus.) This is doable.

[michaelvoliveira]

#7182 has a patch that closes #4594 and part of this.