This is going to be a bit controversial and disliked by BeOS die-hards but I’d like to have the application name in bold next to the icon following the Mac convention.
We have the concept of a “key” menu bar that this could hook into. See “The Key Menu Bar” section from the BeBook and SetKeyMenuBar()
On Classic Mac OS and BeOS there wasn’t a good place to put application-wide menu options so every app put them in a different place making users have to go hunting for the option. This makes it consistent.
I brought this idea up before frustrated that Tracker puts its Preferences in the Window menu and that makes it hard to find.
The About option is an application specific menu item so it makes sense to be in the app menu even if some people don’t understand why.
Yeah, that’s indeed a good point. Also jscipione’s point about the position of the Tracker preferences.
OTOH, a lot of applications will have very few items in that menu, so that this consistency comes with a price tag, too.
If the help menu is not context sensitive, it should end up there, too, then.
However, I’m not entirely sold on the idea of having the icon there, either yet. Sure, it’s space conserving, but also less intuitive, and might look like too much depending on the layout of the window. Other options would be
the application’s name
“Application”
“App”
or a combination of the above with the icon as jscipione suggested. I wouldn’t like having that menu in bold letters. That makes perfect sense on macOS, as you otherwise cannot really tell which menu you are seeing right now, what is the active application. We don’t have that issue, though. We have potentially less space in the menu bar, and should use it better.
Also, an icon would clash with Tracker’s draggable icon in the upper right (which I personally use quite often).
I think there are many things that need discussing if we want to have a general application menu.
I am very much against having an Icon only menu. It took me over 2 years to figure out that Visions app menu was in that icon. The discoverability is awfull, and the legibility of hvif icons on arbitrary backgrounds is questionable.
Having an item that could be a icon+text or text only per user preference could make sense, but only if it is using the existing menu layout classes…
In the “Program” menu, according to our interface guidelines
Program: Items related to operating on the program itself
About … Shows the About window. This is not a commonly-accessed item, so do not provide a keyboard shortcut for it.
Settings…Show the window which is used to customize settings for your program. This can be a submenu if your program only has a couple of settings.
Quit (Command + Q) This should be the bottom item in the menu and a separator should go above it. Clicking on this item should close all windows and quit the program.
I don’t think I have ever seen an application having a “Program” menu. IIRC, the interface guidelines have been single-handidly written by DarkWyrm and did not get too much attention or discussion.
But consistency should definitely be an important part of the UI.
I guess you wouldn’t have needed two years to find the Vision app menu, if all applications would work that way. Intuitivity is important, but IMO it’s less important than usability for the experienced user.
IMHO as a simple user, you will recognize something in the menu bar as a menu if it looks as other menus. It’s a matter of consistency. I mean that all menus should have an icon or, text plus icon or, text only ; otherwise a single icon can be mistaken for decorative.
This also means that if you’re using icons, the symbol used should representative for all entries in that menu. If it isn’t your menu may end up like these ugly hamburger menus that are painful to navigate.
An example is tools icon to represent settings (or parameters) menu, it is easily recognizable and commonly used. So, I would let this one outside the app (or program) menu.
I’ve used these as guidelines for application development, and have seen it used that way in code review. Anyway my point was that we already have a decision for this particular issue, so we could now make our applications conform or change the interface guidelines, I don’t think an api enforcing consistency would help here.
Sure, but occasionally we notice something in there that doesn’t match actual usage, and we fix the document to match reality. And sometimes we change our collective mind about things, as well.
I can’t think of anything having a “Program” menu, but I think we have some litteral “Application” menus, some with the application name, ano Vision with an icon-menu. And most applications that work with files put the items in the File menu (for quit), in Edit (for preferences) ano in Help (for about). I think that organization is more common since a lot of apps do operate on files and the windows correspond to individual files (documents, projects, …) being edited or viewed. There are some exceptions where a File menu makes no sense, and only these currently get some kind of “app” menu.
I think it would be most consistent to always have an “app-icon” menu (or “Application”, or “{%appname%}”, but I’d prefer icon-only) with app-relevent entries (Quit, Settings, Help, About…). Those are simply always in that menu, no matter if the app has a “File” menu.
Having “Settings” under “Edit” always bothers me; “Edit” is for commands to pertaining to the open document, not to change the global app settings.
With only “About” in most cases and occasionally a “User manual” item, an extra “Help” menu isn’t worth the space in the menu bar. They fit nicely into the app-specific items in the “app-icon” menu.
There are two types of things that are commonly called settings.
Some are indeed settings that will apply to everything you will do next, they are determining the behaviour of the app itself and sometimes default values. They are persistent and they certainly belong to an app menu.
But some other are preferences that will apply to the current job (for example, the document that you’re editing), they sometimes reset to a default value when you restart the app and IMHO they deserve their own menu for quick access. Seeing those in an Edit menu doesn’t hurt me. Unfortunately, most of time, both types are happily mixed in a single page.
If there are document specific settings, there’s very likely a “File” menu to open/save docs. I’d prefer to put those settings there instead of “Edit”. Also, they mustn’t be called “Settings” to avoid confusion with the app settings. I suggest “Properties”.
These types of settings should go under ‘File > Properties’.
This is what Google does with their workspace UI, although they call it “page setup” since they are productivity focused. Therefore, there is quite a bit of precedence for putting it there.
I don’t consider this bike-shedding. It visually impacts the GUI of every application and it’s OK that everyone can comment and we can judge the reactions of users and devs.
I’ll leave it to the Haiku devs more familiar with API creation to decide if an entirely new class BApplicationMenuBar is needed, or the BMenuItem gets extended to show an icon or whatever. Doing the latter, we trust the devs to respect the HIG as they already do with all its other rules.
You’ll definitely need more patience, openness and persistence, if you plan on doing any UI related work.
There is still a lot to discuss, and you’ll need actual arguments if you want to convince people of your solution.
I’ve given some that weren’t countered yet, for instance. This is not bike-shedding, it’s a discussion, and I would welcome you to take part in it in a constructive way.
As for the extra class, there are quite some arguments on both sides that could be discussed.
For example:
If the application has not yet been translated to the current language, will the menu appear in a mix of languages (as in macOS) with that BApplicationMenu class?
Maybe we’ll come to the conclusion that we want the menu to be configurable (whether it shows an icon or text). How should that even be possible without a dedicated class?
In any case, integration into BLayoutBuilder should not be an afterthought. It could simply have methods like AddApplicationMenu(), and AddSettingsItem() that you can use if you want, that will give you full control over the final menu.
Well, I kept coming back to see what had changed, anyway, because I was always fascinated by Haiku’s potential.
I don’t recall seeing anything that fundamentally disagreed with my proposal. The only yet-to-be-countered argument that springs to mind is about an icon menu clashing with another icon menu in one application, which I can only disagree with because if anything the presence of two icon menus at either end of the bar mutually strengthens the discoverability of both.
If the user’s computer is set to a language, then the application should display as much as it can in that language unless, for whatever reason, the application chooses to force a specific locale. As it stands, I have (so far) not done anything novel in this regard, so all functions as it would in any other menu item present in the system applications.
.
.