Closed nicoburns closed 1 month ago
@purajit Perhaps you might have a recommendation?
(Just a disclaimer I'm not a Mac developer, just an infra engineer who happened to look into this issue, and if anyone has differing opinions they're probably more correct than mine)
I actually did wonder about what to do for the window
example in that PR. As for the general
case of standalone non-bundled applications, I agree it doesn't make sense to have every
developer explicitly set ActivationPolicy
. I see that NSRunningApplication
provides bundle
information via bundleIdentifier
, which should help us out here.
The value of this property will be nil if the application does not have an Info.plist.
I can PR this some time tomorrow, and hopefully that would mean the window
example should
work as expected with no changes. If this is serious/urgent enough (like blocking a release), I'm
OK with having my PR reverted, and I can re-do it with the bundleIdentifier
fix.
And apologies to anyone who hit this problem! Since a release hasn't yet been cut, I hope it didn't impact too many people, and that this was caught early.
Thanks for submitting the issue and both PRs, I prefer the solution in https://github.com/rust-windowing/winit/pull/3961.
changelog
module if knowledge of this change could be valuable to usersThis fixes https://github.com/rust-windowing/winit/issues/3958. But possibly the default in Winit ought to change back, as it doesn't seem right that all users on macOS need to set this policy.
If I'm reading https://github.com/rust-windowing/winit/pull/3920 right, then it may be that this needs to be explicitly set when a rust binary is run standalone, but will be set automatically if the rust binary is wrapped in a macOS app package. I'm not quite sure how best to handle this. Perhaps we can detect which environment we're in somehow.
Unfortunately
NSApplication::activationPolicy()
seems to return2
regardless of whether thesetActivationPolicy()
method is called, but keyboard events only work if it is.