Show triggers when opening menus with keyboard

[humdinger]

There's the option "Always Show Triggers" which will always underline the letter for the keyboard shortcut of a menu item. If you deactivate this option, shouldn't the underlining at least appear when accessing the menu by keyboard (ALT+ESC)? I think that'd be the correct behaviour, else the "Always" makes no sense.

[axeld]

Menu preferences are gone.

[Prognathous]

Are Menu preferences coming back?

Prog.

[humdinger]

Probably not, IMO. Options should be limited to the absolute essentials. I don't think the Menu prefs held those. If there were any, they should move to Appearance prefs (or whatever that will be named at the end.

[leavengood]

I'm taking this over and re-opening it, as I think it is silly for our menu code to create triggers which cannot be seen.

They are indeed there all the time, they are just only drawn when the "Always Show Triggers" option is set to true, but it defaults to off. With the deletion of the Menu prefs there is no way to set it now (beyond writing a program to call set_menu_info().)

But I think what Humdinger mentioned in this ticket is completely valid and had nothing to do with the Menu prefs, so Axel closed it incorrectly IMO.

So I'd propose showing triggers when a menu is opened with the menu keyboard shortcut Alt-Esc, as described in this ticket.

Whether we also want to re-show some of the menu options in the Appearances preflet is another issue.

[leavengood]

Taking ownership.

[axeld]

FWIW, I completely agree with you. Have fun digging in the menu code, though :-)

[Disreali]

Any progress?

[leavengood]

Replying to Disreali:

Any progress?

Triggers can be turned on fairly easily by calling a particular API function as mentioned previously, but I had some trouble figuring out a clean way to only show them when Alt-Esc is pressed. As Axel implies the menu code is a disaster. So this still needs work.

[leavengood]

I decided to start looking at this again. I hacked up a solution but it is not very nice. Basically since BWindow opens the menu bar when Alt-Esc is pressed, I stored the fact that the keyboard opened the menu in a boolean in BWindow. I then check that when drawing triggers in BMenuItem, and then reset it to false when BMenuBar is done tracking the menu. It definitely works but is obviously not ideal.

Unfortunately trying to pass some sort of boolean to StartMenuBar to indicate it was started with the keyboard is also quite tricky for two reasons:

1) The signature of StartMenuBar cannot be changed without breaking Deskbar (and I even tried fixing it without much success.) Though at this point this is something we can and probably should fix in another way, like just making StartMenuBar public. I don't think that would break compatibility, but if I'm wrong let me know.

2) The menu tracking code is messy, as said in previous comments here. Even if I could pass in the "was started with the keyboard" boolean to the menu tracking code, somehow passing that in to all the submenus does not seem that easy.

Also since it has never really been used the trigger handling code is a bit buggy. For example it doesn't close the menu when it triggers an item, and when I tried fixing it there were still issues. It also doesn't trigger submenus.

I did some tests in BeOS and there are definitely a lot of things we need to fix in our menu handling to match even what BeOS did. Though I did discover a pretty major bug which seemed to cause a deadlock when using triggers. I'm documenting the BeOS behavior (the good and the bad) so we can try to copy the good but not the bad :)

But I think to fix this properly we need a proper menu state tracker class which Stephan mentioned at some point.

[bitigchi]

I miss these in modern operating systems very much...