Proposal: Add mac_default_menu

[geekynils]

Hi Floooh,

Here is a proposal for a default menu on the Mac that includes hiding / showing and quitting!

Thanks again for the amazing sokol library!

resolves #362, resolves #265

[meshula]

FWIW, I always hack something like this in, otherwise people complain about cmd-Q not working. I always have to remember to do it, so I'd be in favor of having something like this in the lib.

[floooh]

Just copying my replies from Twitter :)

"The PR has a few problems, like hardwired non-localized strings and hotkeys. TBH I would prefer to add the necessary hooks so that user-code can setup the menu outside sokol_app.h (it might even work already since NSApp is a globally visible singleton)."

"...I'll try to prioritize this after I'm done with the current WebGPU update though, I'm thinking about one or a handful macOS specific functions or sapp_desc items to setup a minimal main menu on macOS with user-provided strings."

"(e.g. I realize that user-side code is a problem because of the ObjC requirement)"

[floooh]

Just copying my replies from Twitter :)

"The PR has a few problems, like hardwired non-localized strings and hotkeys. TBH I would prefer to add the necessary hooks so that user-code can setup the menu outside sokol_app.h (it might even work already since NSApp is a globally visible singleton)."

"...I'll try to prioritize this after I'm done with the current WebGPU update though, I'm thinking about one or a handful macOS specific functions or sapp_desc items to setup a minimal main menu on macOS with user-provided strings."

"(e.g. I realize that user-side code is a problem because of the ObjC requirement)"

[geekynils]

Thx for the quick replay! If I understood correctly you would rather not have a default menu but an easy way to hook up Mac specific things such as the menu. Could we not have both? A default menu unless the user overwrites the default one? But the default one would not be localized then (otherwise I would have to add localization in all the major languages I think).

So far I just added it to NSApp.mainMenu in the init_cb which works but is probably not the proper way to do it.

[floooh]

Could we not have both?

Yes ideally. Every sokol_app.h application should have at least a default menu with Quit, Hide, etc... but the strings must be provided externally, not hardwired to English, maybe in sapp_desc.h. For more advanced stuff the user needs to 'fall back' to ObjC outside sokol_app.h (by directly setting NSApp.mainMenu)

[meshula]

The precise moment in an NSApp when you can successfully create menus is at the top of this function:

@implementation _sapp_macos_app_delegate
- (void)applicationDidFinishLaunching:(NSNotification*)aNotification {

before then, setting the menus won't work. This function creates windows and sets timers, and so setting menus after it finishes introduces a small indeterminancy as to when the menus will be created. For my own purposes, a callback in this function where I can poke in my own menus, and do other mac specific initialization is ideal. I think the best place would be after the sapp is fully initialized and the metal device is created, but before any deferred mechanisms, such as timers are started.

[alterae]

for what it's worth, doing this manually isn't hard (you just call some ObjC from your init callback. fairly straightforward in both C and Zig)

it is, however, annoying boilerplate, so i'd love to see something like this get merged

(honestly i blame apple for making it as annoying as it is. pretty much every application needs these menus but if you're using AppKit you need to build the menus manually)

if anyone is interested later i can post the implementations i've done in my own code (ObjC from C and Zig, as well as "pure" Zig). they're much, much more barebones than this PR or the default menu that SDL provides, tho (literally only offering a quit button)

speaking of, it may or may not be worth looking into how SDL attacks this problem, as they seem to consider their solution production-ready