Another design option: the application icon is placed on the right side, like in Tracker. And for this icon can be assigned individual functions, depending on the application.
So, there is no need to change the existing menu design.
Theoretically, yes, But someone would have to do it.
Yab accesses a subset of the Haiku API and development on it has stalled. The github repo hasnât been updated in five years. Iâm guessing there would be some catching up to do first. Haiku has moved on in that time. It really is amazing that yab programs I wrote twenty years ago still work.
And frankly, if someone were to take on this noble task of bringing yab up to date and extending it, the first thing I would ask for is not your code, but access to the rich-text editing we see in StyledEdit and to the translaters.
What X512 is trying to tell is that most modern apps donât use BMenuBar directly, they use BLayoutBuilder that allows to build a menu in a much more compact way. Having to use a specific class that is not integrated in BLayoutBuilder will actually be harder than not using it, and so, your approach goes against what youâre trying to achieve in that case.
So whatâs needed is actually an extension to BLayoutBuilder (or even directly to BMenuItem) to add an icon menu item (since we already have the icon menu item class).
3 Likes
Yab is currently maintained by the BeSly guys and had its last release in March 2024,see BeSly Software Solutions.
I donât see a source repo anywhere,but they have a bugtracker and maybe they accept feature requests,itâs worth a try at least.
Thanks for the link. Iâm glad someone is still minding the shop. But looking at it, itâs pretty much in maintenance mode.
I havenât looked at the BLayoutBuilder code, but I canât imagine that would be terribly hard if it were deemed strictly necessary to get this through the door in the first place. At least in the case of menus, the code looks pretty much identical in both approaches, minus a few .s and plus a few ->s.
Does that mean that the BLayoutBuilder doesnât support icon menu items? If so, which came first?
You should ask @lorglas who has done the most recent updates at haikuports.
icon menus are not fully part of the standard API yet (so we should fix that first). And BLayoutBuilder is somewhat unfinished, for example itâs also missing support for BBox and probably a few other things. But all that can be fixed.
Well, if those werenât blocks for either of those to make it into the OS, then I donât see why something like not being totally integrated into BLayoutBuilder should necessarily be a blocker for this. Especially since it doesnât even preclude the use of BLayoutBuilder.
Hi michel, i prepare the 1.8.3 release for yab. I have some little issue left. the last version of yab is the 1.8.2 release date 2024-03-21. And if you have some issues, write a PM or use the bugtracker for yab. I will look, if i can implement this in one of the next version.
2 Likes
Itâs not a blocker. Itâs just questionable whether you gain a lot (or anything) by introducing a new class for this. Having a method to add an icon menu would be enough, or, if you really wanted it, methods to add the quit or settings menu items.
IMO I think itâs rare that apps have an âApplicationâ menu. And I would find it pretty much counterintuitive to have an extra menu just to place the quit item in (or those other two items tops). Itâs wasted space in the menu bar for very little extra use. I never have an issue to determine which window belongs to which application. They usually look very different anyway. I fail to see the advantages. And I also would not really like having an extra icon directly above the tool bar.
6 Likes
Yes, but the argument is that an app should have an application menu. And if thatâs true, then why merely hope devs will do it manually when they can get it for free instead? Itâs both easier and guarantees consistency.
Itâs an Apple Mac convention - every Mac application has one, though with a text head label rather than an icon. 575âs proposal combines that with the Mac concept of the 
menu item, which on Macs is a systems-related menu.
Considering that BeOS and Macs had a shared history in terms of personnel and design philosophy, I think it is a natural development for Haiku.
3 Likes
Not really. Be also took distance from Apple in many ways, and inspiration from other places when they did things better.
Another idea Iâd like to experiment with is allowing apps to add menu entries to their deskbar entry menu. And maybe also other things like being able to show progress bar status there where applicable (for example for Tracker copy operations, or Web+ downloads). That may be easier if there is a clearly defined âapplication menuâ. That would make more sense if the inspiration is the one from MacOS: the idea there is that that menu is accessible easily even if you donât really know where all windows for that app are, and it is not specific to one single window. It works in Mac OS where there is a global menu bar, but maybe not as well in Haiku with the menu bar being inside each window.
But then it may not need to be repeated into each window? Having it in DeskBar may be more useful, but if itâs just the âQuitâ option, thatâs already there.
2 Likes
While one may overlook that the app settings, quit, help etc. have nothing to do with files, those are often found under a âFileâ menu. But where to put them if the app doesnât deal with files? In an extra âApplicationâ menu; some use âAppâ, others the application name as menu label.
An app-icon menu would make this consistent, uses less space and has all the other minor advantages mention further up.
5 Likes
Yes, but it do not need introducing BApplicationMenuBar, only consolidating existing File/Application/< application name > menu to BIconMenuItem.
1 Like
Absolutely. And thatâs what Iâve been saying from the start. 
1 Like
This is how a platform remains ever cursed with inconsistency. An OS should be opinionated about some things, and make it easier for developers to respect that opinion than not.
There are smaller things that bear consideration than merely the presence of certain menus or menu items, such as menu items having consistent shortcuts, consistent naming, consistent location, &c. I am honestly puzzled that some here would rather burden themselves (and others) with achieving consistency in these little things manually instead of allowing the OS to do it for them. After all, devs would still have an option to build menus that suit their fancy manually if they felt it was strictly necessary. There is no downside â and many upsides â especially if the idea itself is popular, which this one seems to be.
2 Likes
I already said significant downside: your BApplicationMenu currently do not support adding custom items to application menu using layout builder. This should be solved first before going forward.
2 Likes
That is an (extremely minor, in my opinion) implementation detail that is almost entirely beside the point of the thing itself.
If we agree that the idea itself is good and worth doing, then it could be worth eventually undertaking some extra effort to make it work in the LayoutBuilder DSL, but I feel that that is a strictly different conversation to this one, however related.