macOS: Unbundled window activation hack#1318
macOS: Unbundled window activation hack#1318august64 merged 19 commits intorust-windowing:masterfrom
Conversation
ghost
left a comment
There was a problem hiding this comment.
This all looks really complicated. I believe the conventional way to do this is to simply call [notification.object activateIgnoringOtherApps:YES]; in the applicationWillFinishLaunching: notification for the NSApplicationDelegate. Is there a reason this doesn't work?
|
@aleksijuvani this PR exists specifically because that doesn't work, though you're free to try yourself. |
|
@vbogaevsky would you be able to take a look at this? |
|
@francesca64, I'll review and test it this night. |
vbogaevsky
left a comment
There was a problem hiding this comment.
First, I tried to recreate uninteractable state on master with window and window_run_return examples and was unsuccessful.
When the app started, if it was not in focus, it got into focus automatically. Was I doing something wrong?
Then I've tried same procedure on merge branch, and both times macOs dropdown menu was inaccessible until I switched to Finder and back to the application. Is it intended behaviour?
|
@vbogaevsky that sounds like the opposite of what I'd expect; what you observed on (Enabling info logging can help verify what's happening as well, though that would require plugging in |
vbogaevsky
left a comment
There was a problem hiding this comment.
Currently on MacOS Catalina when an app starts it gets into focus, but drop down menu does not respond until you switch to another app and back again.
|
@vbogaevsky in which case? I'm having trouble following you, so being more explicit about context would help me a lot. |
|
@francesca64 in both cases (master and PR branch). |
|
@vbogaevsky ah, thanks. I'm able to repro that, but it doesn't seem to be a regression? How acceptable is this PR? |
|
@francesca64 It's not a regression indeed, and I believe we can merge after resolving conflicts in |
|
@vbogaevsky thanks! (I didn't notice you'd already solved the conflicts, so double thanks! Now I feel silly for having made those merge commits.) |
cargo fmthas been run on this branchcargo docbuilds successfullyCHANGELOG.mdif knowledge of this change could be valuable to usersThe explanation for this PR is actually in a wall of comments, so check the diff for context. I have a tendency to view winit as a Rosetta stone of windowing, hence the thorough commenting...
I scanned through the issue tracker, and it doesn't look like there's an open issue for this. You'd think someone from Alacritty would've reported this already, but since Alacritty comes so nicely bundled, only someone developing Alacritty would be able to hit this. I also suspect that there aren't many people developing with winit on macOS in general.
As an exciting bonus, I removed the commented-out cruft I left in
app_delegate.rslast year. It was just copy-pasted from the iOS backend, which I was using as a reference. It was all intended to be removed, but I forgot to ever clean it up.Solution derived from this Godot PR: godotengine/godot#17187
Equivalent GLFW issue: glfw/glfw#1515