-
Notifications
You must be signed in to change notification settings - Fork 919
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move ControlFlow
as methods on EventLoopWindowTarget
#3042
Comments
In favour, though I actually think we should be removing it, and make its functionality available on the event loop that's passed to the closure instead. |
Even better! Let's do that. |
ControlFlow
a structControlFlow
as methods on EventLoopWindowTarget
I think to do it properly though, we need to change impl EventLoop<T> {
fn run(self, event_handler: impl FnMut(Event<T>, RunningEventLoop<'a, T>)) -> Result<(), Error>;
}
impl RunningEventLoop<'a, T> {
fn set_wait(&mut self);
fn set_poll(&mut self);
fn set_exit(&mut self, code: ...);
// ... Other `ControlFlow` methods
}
// Stuff that can be done both before and after the application starts
//
// Should ideally be #[inherent], but that's not possible yet.
trait EventLoopTraitBikeShed: Sealed {
pub fn available_monitors(&self) -> ...;
pub fn primary_monitor(&self) -> ...;
pub fn listen_device_events(&self, ...) -> ...;
}
impl EventLoopTraitBikeShed for EventLoop<T> {}
impl EventLoopTraitBikeShed for RunningEventLoop<'a, T> {}
impl Window {
// Should be changed to `RunningEventLoop` in future, as `EventLoop` doesn't actually work on macOS
fn new(event_loop: &mut impl EventLoopTraitBikeShed);
} This would, apart from removing
|
Is this really required to get rid of |
I remember experimenting with it before, I think it kinda is if you want to avoid interior mutability on the control flow. But maybe not, if not, feel free to do that first! |
I would support moving these methods to the window target. |
We already have the |
On Web there are currently a bunch of ways to implement
ControlFlow::Poll
, they each have different tradeoffs. Unfortunately there is currently no way to add platform-specific functionality toControlFlow
the way usually Winit does: with extension traits.My proposal to solve this problem is to make
ControlFlow
a struct, internally it would probably still use an enum, but the point is to make that private so we can add platform-specific functionality through extension traits. It already provides methods to set theControlFlow
.Happy to do the PR for all platforms.
EDIT: See #3042 (comment), which is an even better solution imo.
The text was updated successfully, but these errors were encountered: