Allow users to take control of the macOS menu bar

[maroider]

The ability to manipulate the macOS menu bar is important for GUI applications, but doing it is currently impossible with Winit's current API.

Setting and accessing the menu bar requires going through NSApplication, which Winit currently wholly owns, and doesn't expose anywhere. One approach here would be to expose NSApplication directly, but I guess that's not the direction we should go in, given that EventLoopWindowTargetExtMacOS.hide_application and EventLoopWindowTargetExtMacOS.hide_other_applications are just thin wrappers around NSApplication methods (?).

Based on this, I propose that a set_main_menu and a main_menu method are added to EventLoopWindowTargetExt, which wrap setMainMenu and mainMenu respectively. This represents the minimal API needed to let users take control of the menu bar (arguably, one might be able to make do with only one or the other).

This may or may not have to interact with #1583 in some way, but I haven't thought too much about it.

[LoganDark]

You can obtain the NSApplication from anywhere in the process using [NSApplication sharedApplication]. I believe the fruitbasket crate provides this functionality and more.

[maroider]

You can obtain the NSApplication from anywhere in the process using [NSApplication sharedApplication]

Funnily enough, the hide_application and hide_other_applications methods do this, but I seem to have missed it.

[ArturKovacs]

I don't think such an API should be added to winit, because:

• It's fairly complex
• It can be done from outside of winit as @LoganDark pointed out
• It is a macOS-only feature, as on other platforms, it's the application's responsibility to render the menu-bar (which we definitely don't want to try to implement in winit)

Although I am a proponent of merging #1583 because that addresses the use case of "I just want my simple little application to feel native on macOS".

[maroider]

It's fairly complex

It doesn't seem very complex to me, as it's just two wrapper methods.

it's the application's responsibility to render the menu-bar (which we definitely don't want to try to implement in winit)

I wasn't really proposing that Winit add such functionality, so I'm not sure what you're addressing here.

---

In any case, since this requires users to reach for macOS native APIs themselves, then I guess making them call this particular set of methods themselves isn't too much to ask of them.

[LoganDark]

In any case, since this requires users to reach for macOS native APIs themselves, then I guess making them call this particular set of methods themselves isn't too much to ask of them.

I agree. [NSApplication sharedApplication] is simple enough that people who want to do things with it should know how to call it themselves. When you're pulling in the objc crate and cracking your menu bar knuckles, you don't need winit to expose methods to send trivial objc messages for you.

[ArturKovacs]

I don't know what's with me today. I completely missed that you only proposed to expose those two functions. But then just exposing those functions wouldn't help too much as you pointed out as well.

it's the application's responsibility to render the menu-bar (which we definitely don't want to try to implement in winit)

I wasn't really proposing that Winit add such functionality, so I'm not sure what you're addressing here.

The part of the sentence you quoted was just explaining why this is a macOS-only addition but again when I wrote that sentence I thought you were proposing to define an API for constructing the entire menubar with all its sub elements.