feat: added MacOS menu #1583

casperstorm · 2020-05-28T17:41:21Z

This is an WIP PR which shows a way we could add a generic MacOS menu into winit.
Let me know what you think, if this is something you could see in this repo, then we could collaborate about the details, formats, where to initialize the menu etc.

Tested on all platforms changed
Compilation warnings were addressed
cargo fmt has been run on this branch
cargo doc builds successfully
Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
Created or updated an example program if it would help users understand this functionality
Updated feature matrix, if new features were added or implemented

Fixes #41.

casperstorm · 2020-05-30T19:01:02Z

@kchibisov, you mentioned you had some ideas here. Do you mind sharing them here?

# Conflicts: # Cargo.toml

adamnemecek · 2020-08-08T20:41:51Z

Cool feature. Hope this gets merged!

OneSadCookie · 2020-08-28T00:45:35Z

+1 for this; I won't use winit because winit apps don't behave anything like a standard Mac app, and this is a big step forward.

This is very English-centric, should you perhaps call NSLocalizedString (or if winit has a blessed localization solution, possibly use that) for the menu & item titles?

src/platform_impl/macos/mod.rs

OneSadCookie · 2020-11-21T19:29:56Z

This has been open six months now, what do we need to do to get it merged?

kchibisov · 2020-11-21T19:36:33Z

This has been open six months now, what do we need to do to get it merged?

I haven't seen macOS maintainers in winit for similar amount of time, so someone with macOS should review it. I have macOS machine now, will try to look into it tomorrow, but I'm not a macOS maintainer.

casperstorm · 2020-11-21T20:16:02Z

I found a error myself where the application is not interactable initially launched. If you switch app, and then back then you can interacte with the menu. Druid has fixed it in this commit: linebender/druid@05311d1#diff-5d6b8d2cc218bec3a8ee3ef9c4c47c61

We should handle this in this PR before we merge.

adamnemecek · 2020-11-21T20:24:27Z

Also, how exactly can my app observe that a menu item has been clicked? Sorry if this is an obvious question.

adamnemecek · 2020-11-21T20:41:01Z

I think that we need to think about the API. The way it works right now is that NSMenuItem has a selector and target properties and when the menu item is clicked, the system invokes selector on target. This seems kind of terrible for Rust since this would force me to deal implementing objective-c methods on my Rust structs.

I think that a better API would be adding a new WindowEvent case (compiled optionally for macos), called something like MenuItem which will allow the user to handle menu item events just like any other event when they are handling winit events.

The way to do this is adding a new struct

pub struct MenuItem {
     name: String,
     ...
}

and then add some APIs to Window to manage (add, delete) menu items. When you register a new menu item, winit dynamically adds a new method (named the same as the menu item) to the application delegate. When the application delegate receives the message that the item has been clicked, it simply injects a menu item event into the event stream.

kchibisov · 2020-11-21T20:53:34Z

I think that we need to think about the API. The way it works right now is that NSMenuItem has a selector and target properties and when the menu item is clicked, the system invokes selector on target. This seems kind of terrible for Rust since this would force me to deal implementing objective-c methods on my Rust structs.

The thing is that I'm not sure that there should be any special handling for them, since the handling is always the same for everyone? Like if you do HideOtherWindows, the only way to handle is either ignore or call winit method to hide other windows, since the amount of menu items is trivial.

I'm not sure about providing custom API right now, since it seems like a very complicated approach and requiring user to match arbitrary strings isn't rust API either.

Right now I think providing a common menu handler for everything(that's what glfw does for example) seems like a reasonable enough solution.

adamnemecek · 2020-11-21T20:57:12Z

@kchibisov I don't follow. When I register these menu items and one gets clicked, how does is that information delivered to my application?

kchibisov · 2020-11-21T21:03:48Z

@kchibisov I don't follow. When I register these menu items and one gets clicked, how does is that information delivered to my application?

With the current API it doesn't, macOS just calls a selector you've specified, and I'm not sure if you can generate selectors on the fly, especially if we talk about rust side, however I'm not familiar with macOS API.

@casperstorm do you aware if there's a way to provide a custom selector and identify in that selector from which method you've been called, thus all menu items can share a selector?

adamnemecek · 2020-11-21T21:07:37Z

@kchibisov there is not a simple way to provide a method that would be called by all menu items. You can always do something like forwardInvocation https://stackoverflow.com/questions/9800293/equivalent-of-ruby-method-missing-in-objective-c-ios

however then you have to know if the method you have been passed is a method from menu item.

adamnemecek · 2020-11-21T21:15:17Z

@kchibisov but yes, you can generate selectors on the fly with NSSelectorFromString. The trick is that we would be doing this only on the objective c side, on the rust side, we would just inject a MenuItem event into the event stream.

adamnemecek · 2020-11-21T21:17:57Z

Another way would be to use the NSMenuItem tag property to allow all menu items to share the same selector. This approach might make more sense since you don't have to register the selectors dynamically.

We could then have a

struct MenuItem<T: From<u64> + Into<u64>> {
     tag: T,
     title: String,
}

you would then have to implement an enum that's convertible to u64.

winit would then insert a NSMenuItem with selector set to "handleMenuItem" and with the tag set to tag converted to u64.

Then, in the handler, we would convert the tag back into T and pass it to the user.

I think this is as good as it gets to be honest.

OneSadCookie · 2020-11-21T22:18:34Z

I think it's worth distinguishing between "winit needs working menus to act like a standard mac app" and "winit should provide a general menu interface". The latter is a huge problem, with implications for Windows and Linux as well. The former only implies handling a few standard commands in standard ways.

I don't think we should gate this PR on developing a general cross-platform menu interface.

About, Hide/Show, Quit, can be handled in the standard ways without modifying winit's APIs or sending new events to the user. The other items can be disabled if they can't be omitted.

adamnemecek · 2020-11-21T22:20:24Z

It doesn't need to be general, it can be conditionally compiled for now, but ideally I should be able to use winit to add new menu items right?

OneSadCookie · 2020-11-21T22:23:05Z

Speaking for myself (but also as someone used to consuming GLFW, SDL, etc) I really don't care about custom menu items. I care about "clicking the menubar shows a menu" and "command-Q works as expected and by default".

Not saying winit shouldn't get a customizable menu system in the future, I just think that this is a critical step forward that doesn't require it, and that will be delayed by trying to get that right.

kchibisov · 2020-11-21T22:23:55Z

@adamncasey if you have a solution(code) to a global problem of menu items for macOS, I'm all ears, but I don't care about custom menu items, especially if you really want them you can add some in downstream without many issues.

OneSadCookie · 2020-11-21T22:24:26Z

What this PR delivers already, is all that GLFW and SDL deliver. Parity there is a great first step, and doesn't preclude doing something better in future.

kchibisov · 2020-11-21T22:28:47Z

What this PR delivers already, is all that GLFW and SDL deliver. Parity there is a great first step, and doesn't preclude doing something better in future.

That's my point as well, since it does precisely what glfw does, and winit is kind of on par with glfw in what it should do (maybe except some minor things like providing OpenGL/Vulkan surface, but that's it).

adamnemecek · 2020-11-22T16:18:43Z

Btw instead of let _pool = NSAutoreleasePool::new(nil); you can use the autoreleasepool function. I think that a result, you don't need to be call autorelease. Check out this example gfx-rs/metal-rs@ae3733c#diff-d1b0398de8154e02b9ab104eb1b0206139165ec972a8b62a0378ffc367db79a9L16

adamnemecek · 2020-11-22T16:25:50Z

Also, there's this project called stella2 that does cross platform menu handling https://github.com/yvt/Stella2/blob/c0524f1a18ad4ee72460a0db0d2bdb9fcb48e3a2/stella2/src/view/global.rs#L16

LoganDark · 2021-02-26T05:38:27Z

I think this PR should be merged as-is. Allowing for custom menus can be done later but this is something that is needed now.

casperstorm · 2021-02-26T08:05:14Z

@kchibisov let me know if there's anything I need to do here.

LoganDark · 2021-02-26T08:32:50Z

@kchibisov let me know if there's anything I need to do here.

I think they're waiting on i18n of the menu text. You may as well do that anyway because it's important

madsmtm

I welcome this addition, I think it's something that winit should definitely support out of the box!

However, I'm working on a library myself for supporting this, and for that it would be really nice this was an optional feature (either compilation or a setting on the event loop), so winit and my custom library don't both try to set the main menu!

Haven't looked at NSAutoreleasePool in this review, don't know much about it.

src/platform_impl/macos/mod.rs

src/platform_impl/macos/menu.rs

madsmtm · 2021-02-26T15:32:17Z

src/platform_impl/macos/menu.rs

+
+        // Seperator menu item
+        let sep_first = NSMenuItem::separatorItem(nil).autorelease();
+


We should add the Services menu here (can be done by creating a menu item with an empty menu, and registering that as the servicesMenu)

Hm, not sure it make sense if we don't have any services to add?

I looked into how the Services menu is used. Winit uses a custom NSView subclass for the entire window surface. Applications and custom NSView types have to implement a certain protocol (see "Using Services" in the Apple Developer Documentation Archive). More specifically the NSView has to provide an implementation for validRequestorForSendType through which it must specify whether the currently selected thing is a valid target for a service that operates on the provided types of data. However winit has no idea what is selected currently. Given that winit doesn't provide APIs to handle validRequestorForSendType messages, it's currently not possible to use the Services menu through winit (if I understand correctly). This is somewhat related to #1759 in that it's a macOS specific "event" that a higher level code may want to be able to handle.

Anyhow I don't think we should be concerned about that for this PR. So with all that, just like @casperstorm wrote, it seems there's no point in adding the Services menu.

LoganDark · 2021-02-26T21:37:18Z

so winit and my custom library don't both try to set the main menu!

Can't you grab the main menu after the fact and modify it?

madsmtm · 2021-02-28T01:46:28Z

Can't you grab the main menu after the fact and modify it?

Easily, but would like to avoid adding creating a menu twice, but mostly it's because I'm not sure if changing the main menu after it's been assigned would introduce flicker

LoganDark · 2021-02-28T01:47:46Z

Can't you grab the main menu after the fact and modify it?

Easily, but would like to avoid adding creating a menu twice, but mostly it's because I'm not sure if changing the main menu after it's been assigned would introduce flicker

You won't have to create a second menu if a menu is already assigned. Pretty standard "only create if it doesn't already exist" pattern.

madsmtm · 2021-02-28T01:58:02Z

Sure, I could just support that usecase in my library (which it probably should anyhow), and the flicker, if even present, is probably not that big of a deal; it was just a nicety for me, as a user, to have 😉

LoganDark · 2021-02-28T03:41:19Z

Sure, I could just support that usecase in my library (which it probably should anyhow), and the flicker, if even present, is probably not that big of a deal; it was just a nicety for me, as a user, to have 😉

It's not uncommon for an application to launch without a menu bar and then take seconds to fill in the categories. Seriously, if your library works fast enough for the delay to be called nothing more than a flicker, I'll be impressed.

ArturKovacs · 2021-03-07T17:24:55Z

As far as I understand NSLocalizedString doesn't help with localizing this. First of all NSLocalizedString is a C macro and it doesn't seem to be available in rust. According to the docs, the macro returns what localizedStringForKey:value:table: would return on the mainBundle with the table set to nil but as far as I can tell this doesn't magically translate words. It only translates the things that the developer translated themselves and added to the bundle.

My knowledge is very limited on this and for the most part I don't know what I'm talking about so please correct me if I'm wrong. If I'm right however, then I don't think this PR should be concerned with localization.

ArturKovacs · 2021-04-13T18:30:05Z

@casperstorm if you address @madsmtm's comments then I think I would be happy to merge this PR.

casperstorm · 2021-04-23T19:05:39Z

@casperstorm if you address @madsmtm's comments then I think I would be happy to merge this PR.

Thanks for the suggestions everyone. I have updated, and fixed a few things. There's still some outstandings I would like some help and feedback to solve.

ArturKovacs · 2021-04-24T11:27:57Z

@casperstorm I added a commit to this PR, please pull and test to see if it works as expected. If you are fine with the changes I made, I think we can merge this.

casperstorm · 2021-04-24T11:50:11Z

@casperstorm I added a commit to this PR, please pull and test to see if it works as expected. If you are fine with the changes I made, I think we can merge this.

Thanks, @ArturKovacs. It works as expected here.

ArturKovacs · 2021-04-24T12:17:54Z

Shoot! I completely forgot about the activation policy thing. I removed the line that set the activation policy and it still seems to work fine for me. What was the reason you originally put it there @casperstorm? Does my latest commit still work for you?

casperstorm · 2021-04-24T12:19:06Z

Shoot! I completely forgot about the activation policy thing. I removed the line that set the activation policy and it still seems to work fine for me. What was the reason you originally put it there @casperstorm? Does my latest commit still work for you?

Last commit works for me. Honestly I can't remember why I put it there. It's been quite awhile :)

ArturKovacs · 2021-04-24T14:57:09Z

Thanks for the contribution!

OneSadCookie · 2021-04-24T21:59:29Z

Thank you @casperstorm for doing the work and @ArturKovacs for getting it merged! Been waiting a long time for this one :)

casperstorm added 2 commits May 28, 2020 19:36

feat: added MacOS menu

74b5d65

fix: ran fmt

6c8a56d

Merge branch 'master' into feat/macos-menu

3ef6412

# Conflicts: # Cargo.toml

casperstorm mentioned this pull request Sep 29, 2020

in macOS, Menu bar has no options. ajour/ajour#143

Closed

Merge branch 'master' into feat/macos-menu

78fd112

aloucks reviewed Oct 31, 2020

View reviewed changes

src/platform_impl/macos/mod.rs Outdated Show resolved Hide resolved

kchibisov self-requested a review November 21, 2020 19:36

maroider mentioned this pull request Feb 9, 2021

Allow users to take control of the macOS menu bar #1855

Closed

madsmtm requested changes Feb 26, 2021

View reviewed changes

casperstorm and others added 4 commits April 23, 2021 21:15

extracted function into variable

ca05139

idiomatic formatting

02f8835

Merge remote-tracking branch 'upstream/master' into feat/macos-menu

611d1e8

Set the default menu only during app startup

7f89bcc

Don't set the activation policy in the menu init

a8b7eb1

ArturKovacs merged commit e8cdf8b into rust-windowing:master Apr 24, 2021

maroider mentioned this pull request Apr 29, 2021

feat: WIP Custom menu builder #1921

Closed

8 tasks

madsmtm mentioned this pull request Nov 26, 2021

Event::LoopDestroyed not always emmited #1998

Closed

technicalpickles mentioned this pull request Jun 15, 2022

Add neovide_confirm_quit option to confirm before quitting neovide/neovide#1247

Merged

fredizzimo mentioned this pull request Jun 28, 2023

neovide_confirm_quit option not working when pressing command+q on macos neovide/neovide#1279

Closed


		// Seperator menu item
		let sep_first = NSMenuItem::separatorItem(nil).autorelease();

feat: added MacOS menu #1583

feat: added MacOS menu #1583

Conversation

casperstorm commented May 28, 2020 • edited by kchibisov Loading

casperstorm commented May 30, 2020

adamnemecek commented Aug 8, 2020

OneSadCookie commented Aug 28, 2020

OneSadCookie commented Nov 21, 2020

kchibisov commented Nov 21, 2020

casperstorm commented Nov 21, 2020

adamnemecek commented Nov 21, 2020

adamnemecek commented Nov 21, 2020 • edited Loading

kchibisov commented Nov 21, 2020

adamnemecek commented Nov 21, 2020

kchibisov commented Nov 21, 2020

adamnemecek commented Nov 21, 2020 • edited Loading

adamnemecek commented Nov 21, 2020

adamnemecek commented Nov 21, 2020 • edited Loading

OneSadCookie commented Nov 21, 2020 • edited Loading

adamnemecek commented Nov 21, 2020

OneSadCookie commented Nov 21, 2020 • edited Loading

kchibisov commented Nov 21, 2020

OneSadCookie commented Nov 21, 2020

kchibisov commented Nov 21, 2020

adamnemecek commented Nov 22, 2020 • edited Loading

adamnemecek commented Nov 22, 2020

LoganDark commented Feb 26, 2021

casperstorm commented Feb 26, 2021

LoganDark commented Feb 26, 2021 • edited Loading

madsmtm left a comment

Choose a reason for hiding this comment

madsmtm Feb 26, 2021

Choose a reason for hiding this comment

casperstorm Apr 23, 2021

Choose a reason for hiding this comment

ArturKovacs Apr 24, 2021

Choose a reason for hiding this comment

LoganDark commented Feb 26, 2021

madsmtm commented Feb 28, 2021

LoganDark commented Feb 28, 2021

madsmtm commented Feb 28, 2021 • edited Loading

LoganDark commented Feb 28, 2021

ArturKovacs commented Mar 7, 2021

ArturKovacs commented Apr 13, 2021 • edited Loading

casperstorm commented Apr 23, 2021 • edited Loading

ArturKovacs commented Apr 24, 2021

casperstorm commented Apr 24, 2021

ArturKovacs commented Apr 24, 2021

casperstorm commented Apr 24, 2021 • edited Loading

ArturKovacs commented Apr 24, 2021

OneSadCookie commented Apr 24, 2021

casperstorm commented May 28, 2020 •

edited by kchibisov

Loading

adamnemecek commented Nov 21, 2020 •

edited

Loading

adamnemecek commented Nov 21, 2020 •

edited

Loading

adamnemecek commented Nov 21, 2020 •

edited

Loading

OneSadCookie commented Nov 21, 2020 •

edited

Loading

OneSadCookie commented Nov 21, 2020 •

edited

Loading

adamnemecek commented Nov 22, 2020 •

edited

Loading

LoganDark commented Feb 26, 2021 •

edited

Loading

madsmtm commented Feb 28, 2021 •

edited

Loading

ArturKovacs commented Apr 13, 2021 •

edited

Loading

casperstorm commented Apr 23, 2021 •

edited

Loading

casperstorm commented Apr 24, 2021 •

edited

Loading