rust-windowing / winit

Window handling library in pure Rust

Home Page:https://docs.rs/winit/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

First window created is not in a tab on macOS...

sshock opened this issue · comments

For this test make sure you have "Prefer tabs" set to "always" in system preferences.

When testing the multiwindow example program I noticed:

  • Initial 3 windows created in the code are grouped together with tabs.
  • First window created by hitting a key ends up in a totally separate window.
  • Further windows created by hitting a key do get grouped with that one.

I don't understand why it makes a separate window that first time.

The good news is this problem doesn't occur in at least one downstream project, alacritty. But that just makes me even more curious to know what causes the problem and how one would avoid it.

Can't test it myself (macOS 10.14.6 Mojave doesn't have that setting), but there are commonly smaller issues on macOS when creating windows outside EventLoop::run (which we should reconsider whether to allow at some point).

Could you try it with the first three windows being created inside Event::NewEvents(StartCause::Init) instead?

I tested this using a custom menubar setup (where the "Merge All Windows" option is available), can reproduce that windows created before EventLoop::run are in some way "separate" from windows created inside.

Odd that it doesn't happen in alacritty though, I think they create the first window outside of EventLoop::run?

Odd that it doesn't happen in alacritty though, I think they create the first window outside of EventLoop::run?

Yeah, that's what I thought too, and it makes me really curious how it doesn't have this issue...

Could you try it with the first three windows being created inside Event::NewEvents(StartCause::Init) instead?

Sure, I'll give it a try soon.

I think they create the first window outside of EventLoop::run?

Yes, we create the first Window before EventLoop::run_return on macOS.

Still no idea why alacritty doesn't suffer from this problem, but I have good news: I just confirmed with the multiwindow example program that the problem goes away if I have it wait and create the initial windows inside of the event_loop.run.

A hunch I had was that the application hadn't entered multithreading mode yet and that's what's causing the differences, but that's not it either...

(Can be checked using +[NSThread isMultiThreaded], it changes to true at some point inside -[NSApplication finishLaunching])