Opened 10 years ago

Closed 2 years ago

#4594 closed bug (fixed)

Issues invoking menus via keyboard

Reported by: humdinger Owned by: nobody
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking: #4292, #7070
Has a Patch: no Platform: All

Description

This is hrev33154.

For example:

  • Open StyledEdit
  • Activate menu with ALT+ESC

=> Mouse pointer vanishes (normal?)

  • Cancel menu navigation by pressing ESC twice
  • Try to activate menu again with ALT+ESC

=> Doesn't work.

The mouse pointer is still missing. Only once you move the mouse, the pointer pops back and ALT+ESC works again.

Change History (11)

comment:1 by psycho_killer, 10 years ago

I have been noticing this myself too, that it's not possible to activate the menu with the keyboard again after doing it once. Not even after having written text in the application. Kind of defeats the purpose of operating using keyboard shortcuts if you have to hit the mouse between each action.

It seems this bug is per-window specific. Open two Tracker windows. Do Alt + Esc on one. Doesn't work if you try it again. Switch to the other Tracker window using Twitcher (not touching the mouse). This Tracker window will allow you to use Alt + Esc, but only once.

Regarding the missing mouse pointer thing. This is normal and how it should be. The idea is that in situations where you use the keyboard only you don't need to see the mouse pointer. Move around with the arrow keys or just type in StyledEdit and the pointer goes away. The disappearance of the mouse pointer is actually a feature -- you will also find this in the Mac OS (both classic and X). This is likely where BeOS inherited this feature. In text based application like StyledEdit and Pe it is a good thing that the mouse pointer goes away when using the keyboard since the pointer is only getting in the way -- either obscuring letters or it can be mistaken for the blinking text input thingy. Touch your mouse and your pointer reappears.

In my opinion all document based applications should behave like this in Haiku, not just those where you type. Navigating with the keyboard in ShowImage, BePDF etc should happen without having to see that fat hand pointer in front of your image or text. I also believe that a native Haiku browser should hide away the mouse pointer when using the keyboard arrows for navigation or typing in a text box. Again, this is what happens in the Mac OS, and I find myself missing it on other systems. It's just a nice little detail. I should file this as a ticket of its own, I know.

There exists some other bugs related to keyboard navigation in Haiku. I hope to get around to filing them sometime later.

comment:2 by anevilyak, 10 years ago

Component: Servers/app_serverKits/Interface Kit

comment:3 by Ziusudra, 10 years ago

Version: R1/DevelopmentR1/alpha2

I've been delving into the menu keyboard nav issues and have noticed that it doesn't matter if you use the keyboard to open the menu. You can open the menu with the mouse and then "close" it with the escape key and it will then not open with Alt+Esc.

With cursor left now used to close submenus I think it would make sense to have escape close all menus. Especially since there is no way to do that with the keyboard.

comment:4 by leavengood, 9 years ago

So this still happens, and indeed I've learned you cannot use keyboard shortcuts for menus while the menu is open. Hopefully these are related and could both be fixed at once. But I don't know if I'm comfortable enough with the menu code to attempt to fix it. My attempts so far have not gone well.

comment:5 by mmlr, 9 years ago

Blocking: 4292 added

(In #4292) This seems to be the same for menus in general as reported in #4594 as well. Closing this as a duplicate of that one as it is more general.

comment:6 by mmlr, 9 years ago

Blocking: 7070 added

(In #7070) Seems closing the other one as a duplicate removed the blocked by, adding a direct blocked by to #4594 then.

comment:7 by mmlr, 9 years ago

BTW the cursor disappearing is by design, it's intended to hide the cursor as soon as you start typing so it doesn't interfere with entering text. Whether or not it is sensible to also trigger that on the escape key for menu navigation is a different story. As per the two duplicate tickets this problem also happens when using the menu key to open the Deskbar menu.

comment:8 by Pete, 9 years ago

I've posted a patch in #7182 that seems to fix these issues, and some others as well.

comment:9 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:10 by waddlesplash, 2 years ago

This does not seem to be an issue anymore?

comment:11 by humdinger, 2 years ago

Resolution: fixed
Status: assignedclosed

Indeed. Thanks!

Note: See TracTickets for help on using tickets.