[macOS] Add default Window and Help menus, allow special menu customization.

[bruvzg]

More customizable version of #83408

• Adds default Window and Help (for use in conjunction with [macOS] Add support for native help menu search callbacks, integrate editor help. #83819) menu.
• Allow adding custom items to the Apple, Window and Help.
• Move Editor Settings to the Apple menu (where settings option usually is on macOS).

---

• Production edit: This closes Implement macOS menubar Window section godot-proposals#8500.

[ztc0611]

Excited for this one! 😄 Having ⌘+M for minimize is a great usability improvement. I also might actually use multi window mode in the editor whenever this merges.

However, the editor settings under the Apple menu doesn't work for me, only the original one under Editor. ⌘+, also activates the binding under the Apple menu, so it doesn't do anything besides blink the menu title.

Edit: I fixed it, there was a binding issue. How do I get the fix to you?

[Calinou]

Edit: I fixed it, there was a binding issue. How do I get the fix to you?

I suggest pushing a branch with your changes to your fork and linking it here.

[ztc0611]

Pretty minor adjustment. 🙂 ztc0611@be3a6e5

[bruvzg]

Pretty minor adjustment.

Thanks. Rebased and added missing apple_menu->connect.

[YuriSizov]

We should've probably identified this before, but this has to be done with an enum rather than a bunch of hardcoded strings. We went to great lengths to reduce the dependency on strings in Godot 4 and it's a shame to start introducing something like this back.

I'm not sure how much of a bother it would be to rework it now. Although given it only affects macOS for now, I think breaking compatibility right now is a valid option.

[bruvzg]

It can't be enum, since non-standard menus use it as well.

[YuriSizov]

What non-standard menus and why couldn't they create their own custom IDs for this purpose instead of using strings?

[bruvzg]

Every global menu (or submenu) except the hard-coded list above. It can create its own ID (the only requirement is having some globally unique ID, so it can be RID issued by the DisplayServer, and it's probably would make more sense). But this will be compatibility breaking. Originally, it was intended to be used in the similar manner as PopupMenu string submenu property.

[YuriSizov]

Originally, it was intended to be used in the similar manner as PopupMenu string submenu property.

The way it works is an oversight and should've been changed in Godot 4.0. We're now moving away from strings there as well, see #85477.

Which is what I mean by my original comment, we're now introducing new API (or rather introduced a few versions ago) which follows a bad pattern from the old API.

[bruvzg]

we're now introducing new API (or rather introduced a few versions ago) which follows a bad pattern from the old API.

It's not new, API is from the 3.2.

[YuriSizov]

My bad, didn't realize we supported global menus in 3.x. Well, I still think we should be looking for a way to get away from strings, especially if we're going to be extending this feature more and more.

[bruvzg]

I guess the question is, do we want to:

• Assume that these DisplayServer functions aren't widely used and break compatibility (this won't break existing MenuBar / PopupMenus).
• Add 35 compatibility functions (and String ↔ RID hashmap).
• Or just keep it as is.

Changing ID's to RID would allow simplifying code quite a bit, so it's not a bad idea.

[akien-mga]

TIWAGOS disclaimer :)

My general feeling is that I'm not fond of 48 macOS specific global_menu_* methods in the generic DisplayServer, but that's something I had already raised in #25656 and now I've accepted that it's just the way we can handle platform-specific APIs currently. But that's a different problem and out of scope for this discuss, it just colors my relationship to these APIs still :P

And so likewise for these string IDs, there's a lot of "sunken cost" that makes me wary of asking for major changes. I think there's room for improvement to have more user-friendly and self-contained API (random idea, a GlobalMenu singleton to host those 48 methods) and it can be worth thinking about, but at least for this PR it's also out of scope IMO, as this just reusing the current status quo.

[YuriSizov]

After a bit of discussion I agree with the above. Let's just keep it somewhere in our mind that it would still be worth it to rework the API to organize it better and de-bloat some global classes. When we do that, we can also consider the RID alternative approach to simplify things.

[YuriSizov]

Thanks!