-
Notifications
You must be signed in to change notification settings - Fork 932
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
Verify event order #3710
base: master
Are you sure you want to change the base?
Verify event order #3710
Conversation
128fb21
to
14bedb6
Compare
When debug assertions are enabled, check that events are emitted in the expected order, and if not, log an error.
14bedb6
to
8968765
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general idea is good, though, we'd need something to run all of that on CI in a crossplatform way.
But as for Suspended
event, I'm still not sure whether we should emit it like that. Probably it won't hurt, but we must ensure that it's semantically the same place on all the platforms, right now I don't think it's the case.
fn memory_warning(&mut self, event_loop: &ActiveEventLoop) { | ||
// TODO: What states are allowed when receiving this? | ||
self.inner.memory_warning(event_loop); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's just a generic event which should be moved somewhere else, like to a separate trait. The ApplicationHandler
today should represent the lifecycle of the event loop in the future, and real events should be on some other traits.
The order that application handler methods are called in relation to each other is somewhat badly documented, and difficult to know for sure if correct. To remedy this, I've implemented a check that's enabled with debug assertions, and which logs if events are emitted in an unexpected order.
I went with using debug assertions, since I don't know of a better way to ensure that this will be tested, but there's of course a cost here in that if we don't catch all the issues, then downstream users will see these errors.
TODO:
Once done, also fixes #3206.