On Unix, expose a way to register file descriptors into the polling loop

[notgull]

Under the hood both Unix backends use calloop, which supports registering arbitrary file descriptors through the polling crate. However, winit usually isn't the only thing running in the GUI system; there's also zbus, accesskit and other things. It would be nice if you could register these systems into winit and poll them without needing to spawn another thread.

Two potential options here:

• Expose a way to register file descriptors in calloop, then receive events as normal through the winit event loop. Then expose a higher-level I/O mechanism in another crate.
• Port from calloop to async-io. This would take a lot more work and be more controversial, but it would allow for seamless integration with zbus.

cc AccessKit/accesskit#337 (comment), @mwcampbell

[kchibisov]

This would take a lot more work and be more controversial, but it would allow for seamless integration with zbus.

zbus is a really poor argument to all of that, since it's the most complicated and bizarre library I've ever used. But generally allowing inserting sources into winit's event loop is a desired solution.

I'd also say that winit should be the one controlling the loop on all the platforms in one way or another, thus it should allow registration of sources on all of them. Otherwise it should be left to a specific backend.

[mwcampbell]

Unfortunately for what we want to do here, zbus doesn't let you get a file descriptor for the connection and drive the I/O yourself; it can only use async-io or tokio. But I've come to appreciate the calloop style of event handling and async I/O in Rust, where the application controls the event loop and maintains sole ownership of mutable state. So ideally I'd like a pure-Rust D-Bus implementation that integrates easily with calloop, without necessarily being coupled to it, just as wayland-rs isn't tightly coupled to calloop. But that would be too much of a distraction from my current work. Anyway, I think winit's support for FD event sources should be designed such that it would work well with such a D-Bus implementation.

[kchibisov]

The current state of winit allows you to plug its fd into your own event loop and poll it on demand, however I'd also like to have some kind of executor eventually, so you can plug things into winit itself.

[mwcampbell]

Yes, plugging things into winit is what I'd prefer, because that way AccessKit could handle D-Bus events on the main thread, possibly with access to the same mutable application state as the regular winit event handler, without requiring the application to replace its event loop.