Added some "how" and "why" docs to event handling.#1032
Conversation
Osspial
left a comment
Osspial
left a comment
There was a problem hiding this comment.
Thank you for contributing these improvements!
I've added some comments where they seemed necessary, but overall these changes are a good improvement.
| //! for e in (window events, user events, device events) { | ||
| //! event_handler(e, ..., control_flow); | ||
| //! } | ||
| //! event_handler(EventsCleared, ..., control_flow); |
There was a problem hiding this comment.
This currently doesn't handle the RedrawRequested model which is... fair, since the current RedrawRequested model is unnecessarily complex and should be revised. See #1041.
There was a problem hiding this comment.
Yeah I didn't try to make a complete example, more a cartoon of how the pieces fit together... because I didn't understand the complete picture. Do we want a full and more complex example?
There was a problem hiding this comment.
I'd like to wait for #1041 to get resolved, since a full example that includes the current redraw complexity is complex enough that it would largely defeat the point of having this sort of example.
There was a problem hiding this comment.
Since it looks like #1041 might take a fair bit of work, should I remove those bits of the docs so we can merge this, or should I update them to reflect the current model so we can merge this?
There was a problem hiding this comment.
Could you remove this for now, but open another PR adding this example, so we can merge it once the #1041 changes have been finalized?
There was a problem hiding this comment.
Coming back to this - we've got a redraw-requested-2.0 branch that implements the new API. There's a clear model for the redraw API there, so if you'd like to re-target this PR against that branch we should be able to merge it promptly.
There was a problem hiding this comment.
Life is rather busy now, so this is squarely in the "when I can get around to it" category.
There was a problem hiding this comment.
The redraw-requested-2.0 branch has been merged onto master.
| //! Some of these events represent different "parts" of a traditional event-handling loop. You could | ||
| //! approximate the basic ordering loop of [`EventLoop::run(...)`] like this: | ||
| //! | ||
| //! ```rust,no_run |
There was a problem hiding this comment.
This is failing the tests, since it doesn't even compile. Change this to ignore.
goddessfreya
added
C - waiting on author
Basically I had these questions when I started exploring the new event API's, and as I figured out the answers I put down more info about how everything works. This is not final, and suggestions are welcome -- the code example in the `event` module docs is particularly dubious, but it's how I'm used to thinking abou things so it only made sense to me once I wrote that. Note that my bias is towards using winit for writing games, so that's the sort of things I was interested in. This may not be valid for more general use cases.
3 participants
Basically I had questions when I started exploring the new
event API's, and as I figured out the answers I put down more info
about how everything works. This is not final, and suggestions
are welcome -- the code example in the
eventmodule docs isparticularly dubious, but it's how I'm used to thinking abou things
so it only made sense to me once I wrote that.
Note that my bias is towards using winit for writing games, so that's
the sort of things I was interested in. This may not be valid for
more general use cases.
cargo fmthas been run on this branchCHANGELOG.mdif knowledge of this change could be valuable to users