event_loop: group core API in EventLoopProvider

[kchibisov]

This helps with portability and defines some top-level structure around the event loop, so in the future, backends can get an idea of what API to use.

This also changes the API to be object safe by using dyn throughout.

--

I think that should help with core split.

[madsmtm]

Thanks, this is what I thought of in #4208 (comment).

[madsmtm]

Nit: Outdated

[madsmtm]

It's not that clean, but until we land #4165, I think you have to keep this cfg, otherwise it won't build?

[kchibisov]

Ah, It'll fail to compile on a different level, thus I can not do much about it...

Maybe the run APIs on their own should be separated into their own Traits, so the impl will be present only when it's actually possible?

[madsmtm]

Maybe the run APIs on their own should be separated into their own Traits, so the impl will be present only when it's actually possible?

Possibly? I'm not sure at the moment.

[madsmtm]

Actually, I spent some more time thinking this over, and I no longer think a trait is warranted here.

Places where it could be useful:

• If Winit wanted to do Box<dyn EventLoopProvider> - but we do not, the top-level crate is always going to know the set of backends that it supports (i.e. that's an enum).
• If some downstream library wanted to do fn my_fn(event_loop: impl EventLoopProvider). The only functions that you can call here though are:
  • run_app, in which case my_fn should instead return a impl ApplicationHandler
  • create_proxy, in which case my_fn should just take EventLoopProxy.
  • listen_device_events, in which case you'd probably want impl ActiveEventLoop instead.
  • set_control_flow, in which case you'd probably want impl ActiveEventLoop instead.

So I think we should close this PR, and move forwards with #4208 without.

Apologies for making you submit this PR, and then ending up changing my mind!

[kchibisov]

If Winit wanted to do Box - but we do not, the top-level crate is always going to know the set of backends that it supports (i.e. that's an enum).

While that is true, there's another side of the issue. Given that those core traits work both ways, the user of the API doesn't really need that in a form of trait, since as you've said, they can manage it themselves, however, backend authors may want to have some kind of API that describes how the backend is expected to operate from the user point of view.

Also, the user of the API wants to store EventLoop in some kind of struct and uses thirdparty event loops under certain conditions, then they'd need a trait of some sort. This mostly an issue with a non consuming API, such as pump_events. Though, consuming is also an issue if you create the event loop and pass further up.

[madsmtm]

backend authors may want to have some kind of API that describes how the backend is expected to operate from the user point of view.

Yeah, I can see that point, though that is kinda also solvable with better docs.

Also, the user of the API wants to store EventLoop in some kind of struct and uses thirdparty event loops under certain conditions, then they'd need a trait of some sort. This mostly an issue with a non consuming API, such as pump_events. Though, consuming is also an issue if you create the event loop and pass further up.

Which is why I think it's fine for us to sidestep the issue and wait with introducing a trait here.