“Quit” and “Settings” I agree with. I don’t mind moving “About” (how often do you really click on that?). But “Help” as the rightmost menu item is by now a firm convention across operating systems, all the way back to DOS.
That’s where the user expects to see it wherever system they come from.
Personally, menu items in the menu bar that don’t open a menu with items, but directly invoke an action (here: open the help file in the browser) make me uncomfortable. That some other OS do it, doesn’t convince me. App-specific commands land in the app-icon menu, simple, logical, consistent.
In addition to this topic, a find function in the help menu, as in MacOS , would be useful in those program with a lot of menus (e.g.: ArtPaint would be a perfect candidate); it’s easy to script an app to do this, it would be easier if this is exposed by the menubar itself
I did not find the button for a while… I looked closely on the menu-bar first!
I agree that every app’s menu should include a function to search the menu items, and that the ApplicationMenuBar would be the perfect place to give users this functionality in any app using it. This feature was originally present in Ubuntu’s Unity environment, and it’s a killer feature that is tragically missing from Linux anymore.
Such ApplicationMenuBar should have a unique hotkey. What combination could it be? A letter is not suitable, because some other element can use it, a number too (this will not be convenient on all keyboard layouts). What if simply pressing the “Menu” button opened the ApplicationMenuBar menu of the active application? Of course, “Deskbar” would not like that…
CTRL/ALT/CMD+ESC?
If we’re talking about a shortcut to bring up a menu search, I think the obvious answer is ALT+Space.
Some keyboard layouts use ALT as a third level key (AltGr). So it should depend on the users settings which of the command keys he uses for the hotkeys. For example I use CTRL.
Yes, in that case, it would be CTRL+Space for you.
When choosing a keyboard shortcut for ApplicationMenuBar, one should avoid possible conflicts with Haiku’s system, native application, and ported application keyboard shortcuts.
It’s kind of outside the scope of the immediate conversation, but I have a whole document drawn up about the future of Haiku keyboard shortcuts. In any case, this specific feature would be implemented in a future update if this gets accepted.
Overall, it seems like support for the ApplicationMenuBar is quite positive. What are the next steps for officially submitting these changes (after a little code cleanup, obviously)?
Please stop posting AI generated stuff. All mentioned Haiku shortcuts are wrong.
Respect the Forum etiquette, esp. paragraph 2 of FAQ - Improve the Discussion.
Hmm, if this is going to be the new look for Haiku, how close can I get to it with yab applications? I do want yab to remain a first-class citizen around here.
Time to experiment, do a little mockup …
Yes, it works. Only the About item has an action assigned to it, though.
#!yab
OpenWindow()
// Main Message Loop
dim msg$(1)
while(not leavingLoop)
nCommands = token(message$, msg$(), "|")
for everyCommand = 1 to nCommands
switch(msg$(everyCommand))
case "_QuitRequested"
case "MainWindow:_QuitRequested"
leavingLoop = true
break
default
end switch
if instr(msg$(everyCommand), "☂") then
if mid$(msg$(everyCommand), 16) = "About" then
a=alert "It works!", "OK","","","info"
endif
endif
next everyCommand
wend
CloseWindow()
exit
// Setup the main window here
sub OpenWindow()
window open 100,100 to 600,500, "MainWindow", "Main Window"
menu "☂", "About", "", "MainWindow"
menu "☂", "Settings", ",", "MainWindow"
menu "☂", "Quit", "Q", "MainWindow"
menu "File", "New", "", "MainWindow"
menu "File", "Save", "", "MainWindow"
menu "File", "Save As", "", "MainWindow"
end sub
// Close down the main window
sub CloseWindow()
window close "MainWindow"
return
end sub
Creating the menu head with a Unicode glyph is easy enough. The tricky part is catching it in the main loop. The standard yab SWITCH..END SWITCH loop chokes on multi-byte input, so you need to create a secondary loop in which you use INSTR and string-splitting to make up for the presence of two extra bytes (or more if you use a CJK character).
Now all I need is a program icon that looks like an umbrella!
It looks a good idea for me. Existing menus like “File“ or < application name > should be probably merged into application icon menu.
I am not sure that it need separate BApplicationMenuBar, maybe manually adding application icon menu to each application is enough. Separate class for HVIF icon menu item is useful through.
If BApplicationMenuBar will add some predefined menu items, it may be harder to customize menu and add application-specific items into it.
I don’t see how that’s true. In every other respect, the ApplicationMenuBar works exactly the same as a MenuBar, so you can add whatever you want.
One of the primary goals of this is to make it easy for applications to be consistent with one another. Asking developers to add this manually is equivalent to them either not doing it, or doing it in subtly different ways to one another. The essential premise here is that consistency and coherency are Good Things, and that developers’ and users’ lives are both made better when we make it easy for developers to be consistent and coherent.
How do you expect developer will add additional menu items to application menu. If menu is created from scratch, it can be easily done with layout builder:
BMenuBar *menuBar = new BMenuBar("menu", B_ITEMS_IN_ROW, true);
BLayoutBuilder::Menu<>(menuBar)
.AddMenu(new BMenu("File"))
.AddItem(new BMenuItem("Close", new BMessage(B_QUIT_REQUESTED), 'W'))
.End()
.AddMenu(new BMenu("Action"))
.AddItem(new BMenuItem("Add", new BMessage(addMsg)))
.AddItem(new BMenuItem("Remove", new BMessage(removeMsg)))
.AddItem(new BMenuItem("Edit", new BMessage(editMsg)))
.AddItem(new BMenuItem("Set password", new BMessage(setPasswordMsg)))
.AddSeparator()
.AddMenu(fAddMemberMenu = new BMenu("Add member"))
.End()
.AddMenu(fRemoveMemberMenu = new BMenu("Remove member"))
.End()
.End()
.End();
Inserting menu items to an existing menu will complicate things.
I think that it is actually easier to adapt all applications in Haiku code tree to new design without introducing some new BApplicationMenuBar, BIconMenuItem will be enough. Work will be straightforward.
It works exactly the same with the ApplicationMenuBar, as shown in the Terminal conversion.
It would one time, yes, but should anything (require) change in the future, it is N times the amount of work and not even guaranteed. In such a situation, at absolute best, you end up with things being subtly different from one another again, most likely forever. Change one thing in one place, not N things in N places.
Do you mean this: Making sure you're not a bot!? I can’t see where application menu is customized here. Attempt to add new items to application menu will break whole layout builder pattern.
Items added to the ApplicationMenu is done at the bottom of that same method, and works the same as the MenuBar, only with a few pre-defined methods to lighten the developer’s burden of maintaining system cohesion. As you see elsewhere, the menu builder otherwise works as expected. There is no reason that the application menu can’t be further integrated into the menu builder, but that’s outside the scope of the topic itself. Not every application even uses the menu builder, as I learned first-hand in converting some apps (which, I would like to reiterate, is usually a question of mere minutes of work, and in some cases seconds).
This work is an argument that certain things belong in certain places and that those things should act in certain ways, and that all of these things should be true all the time.
I don’t know anything about yab, but I don’t see how there would be anything stopping the ApplicationMenuBar/ApplicationMenu being made directly available to it. Is it not calling the same API as a C++ program would be?