Opened 17 years ago

Closed 17 years ago

#1269 closed bug (fixed)

Haiku's BMenu is is different from BeOS's in handling Escape and Alt-W/Q.

Reported by: jonas.kirilla Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc: axeld@…
Blocked By: Blocking:
Platform: All

Description

Escape

In BeOS, when the menu is sticky and the mouse pointer is not held over it, the escape key closes only the topmost menu window, the last one in the chain. This works the same in application menubars, in Tracker's context menu and in Deskbar. Escape collapses piece by piece.

In Haiku, application menubars and Deskbar's Leaf menu are immediately fully collapsed by the escape key, while Tracker's context menu is unaffected. Both cases unlike BeOS.

Alt-W/Alt-Q

In a BeOS application, you can not Alt-W a window or Alt-Q the application while the menubar has a menu open. (Not even shortcuts in the currently open menu have any effect!)

In Haiku, Alt-W/Q work even when in a menu, and I'm guessing the other shortcuts do too. (User error! ;) Anyway is the API safe if this is allowed? Why did Be disallow shortcut use while a menu is open?)

Tracker's context menu/Deskbar's Leaf menu:

In BeOS, Alt-W has no effect on these menu hierarchies. In Haiku, Tracker's menu is collapsed, the root menu left intact, with a submenu saying "<empty>". Deskbar's Leaf menu is reduced to a single orphan menu saying "<emtpy>".

Attachments (5)

screen5.png (60.5 KB ) - added by jonas.kirilla 17 years ago.
Alt-W: Before
screen6.png (18.4 KB ) - added by jonas.kirilla 17 years ago.
Alt-W: After
screen2.png (40.3 KB ) - added by jonas.kirilla 17 years ago.
Alt-W: Before
screen3.png (37.1 KB ) - added by jonas.kirilla 17 years ago.
Alt-W: After
screen4.png (80.0 KB ) - added by jonas.kirilla 17 years ago.
First time that Alt-W:ing the menu has crashed on me.

Download all attachments as: .zip

Change History (10)

by jonas.kirilla, 17 years ago

Attachment: screen5.png added

Alt-W: Before

by jonas.kirilla, 17 years ago

Attachment: screen6.png added

Alt-W: After

by jonas.kirilla, 17 years ago

Attachment: screen2.png added

Alt-W: Before

by jonas.kirilla, 17 years ago

Attachment: screen3.png added

Alt-W: After

by jonas.kirilla, 17 years ago

Attachment: screen4.png added

First time that Alt-W:ing the menu has crashed on me.

comment:1 by jackburton, 17 years ago

Owner: changed from axeld to jackburton

comment:2 by jackburton, 17 years ago

Keyboard navigation in menus is still very WIP, as you'll have noticed :) It needs also some support on the app_server side, since menu windows don't usually get focus, but still needs to receive keyboard events.

comment:3 by jackburton, 17 years ago

By the way, the fact that the application window gets the shortcuts event depends on the menus not getting the focus.

comment:4 by jackburton, 17 years ago

Cc: axeld@… added

Both shortcuts (ALT-W and ALT-Q) aren't added to modal windows. So either we add the kMenuWindowFeel to the check in BWindow::IsModal(), or in BWindow::_InitData(), we change fNoQuitShortcut = IsModal(); with

fNoQuitShortcut = IsModal()
Feel() == kMenuWindowFeel;

I'd go with the former, but I don't know if there will be any consequence. Opinions ?

comment:5 by jackburton, 17 years ago

Resolution: fixed
Status: newclosed

I added the check for kMenuWindowFeel in BWindow::IsModal() in hrev23343. Please review. I'll close the bug, though, since it's fixed.

Note: See TracTickets for help on using tickets.