rust-windowing
Support multiple event loop instances on Windows
This allows multiple event loop instances on Windows.
This is blocked on https://github.com/rust-windowing/winit/pull/3061 as currently using event loops of different types can cause unsafety.
I'm not sure this is really a good idea. Mostly because objects created by different loops can't really interact with each other. Maybe that's not true on Windows, but I'm not sure we should allow such a use case...
Not being able to create multiple windows is a rather major limitation that makes winit not suitable for use in other libraries. If that's out of scope, that should be clearly stated in the readme so libraries can use other alternatives.
Currently It can create windows and Winit is designed to be a low-level brick in a hierarchy of libraries very much imply the ability to create multiple windows.
Not being able to create multiple windows is a rather major limitation that makes winit not suitable for use in other libraries. If that's out of scope, that should be clearly stated in the readme so libraries can use other alternatives.
You can create as many windows as you want with the one event loop. I don't understand why you need multiple loops
See https://github.com/rust-windowing/winit/blob/master/examples/multiwindow.rs
Libraries based on winit all end up creating their own event loops, which makes them not composable. You're unable to actually create multiple windows using libraries built on winit.
@Zoxc well, good for them. But you can't have multiple event loops on macOS for example, you also can't mix winit objects from multiple event loops, since it'll terminate the other loop if you do that.
You need a separate processes for them. What you want can only work on basically Windows, and that's about it.
It also works on X11 / Wayland.
No, Wayland doesn't work like that, it'll need a special API for multiple event loop on Wayland, since it relies on sub-queues. It doesn't work on X11 as well nice, because error handling is per_process so error in one loop can kill other loop.
As I said, no-one doing something like that usually, they just give a handle to library to draw into (see egui), none GUI clients want to do stuff like that, it's wrong.
We could have an option to create as many loops as you want, but why a portable toolkit could enforce a non-portable design? We have exception on wasm, but we have a separate call and wasm just works so much different than anything else that it's fine.
I don't think your arguments about X11 / Wayland hold water. They also do not apply to exposing this on Windows.
I don't think your arguments about X11 / Wayland hold water. They also do not apply to exposing this on Windows.
I'm saying that multiple event loops need a different API to even try to make it work in a safe, reasonable way. Just slapping API which obviously can't work is not the way forward, not that folks usually do it that way, because libraries system libraries have global shared state, which you should be careful about. I'm still not sure why should we try to continue with such designs, just create processes if you really need multiple event loops, that's how usually it's done by clients demanding such API.
Out of all platforms only Wayland with subqueues was designed with the concurrent multi-threaded access to the windows, yet it'll need some sort of Coloring in winit to make it work, since Window created by one event loop can't work with another one.