After the rewrite in #173, the entire events API was overhauled and also made unstable. There are a number of fundamental questions that need to be answered about the events API before we can settle on a stable version of it. This issue is meant to serve as a place to discuss that.
Please keep in mind that the turtle crate is designed for people who are still learning Rust. The goal is not to have the most state of the art event model or to even have the most robust set of events. We want something that will set people up to be able to write interesting programs and we want to avoid teaching them any bad habits that might affect their ability to learn other crates in the future. The final event API we come up with will hopefully be quite simple and easy to teach overall.
Questions
What event model should we use? We current use an event loop, but there are also other patterns like observers, callbacks, etc.
Should we keep the poll_event method or replace it with a blocking/non-blocking pair called next_event and try_next_event?
Should we have a managed event loop like EventLoop::run in glutin or is it important to give the user the ability to structure the loop themselves?
In the event loop, how does the user know when the event loop ends?
Should we return None from next_event or should there be a specific event for when there will no events anymore? How should all of that look?
Before the new architecture, we used to call process::exit when the window was closed
Now that we don't do that, most programs that use the turtle event API end with a panic
Ideally, there would be some event to notify when the window is closed so the event loop can end gracefully and clean up
There is also an implementation concern here: we currently don't send all events because once the window closes, there is no server left to handle further next event requests
We can probably work around the implementation issue using a second IPC channel specifically for events
Which events should be exposed in the Event enum? Right now we have a small set of events but there are definitely a lot more we can/should provide
At minimum, we probably need mouse movement, clicking, and keyboard events
What is the shape of the Event enum? (e.g. MouseButtonPressed/MouseButtonReleased vs. MouseButton {pressed: bool} vs. other alternatives)
Should it be possible to handle the Esc key being pressed and prevent the window from being closed? How would that get implemented?
Should there be a separate EventLoop struct? Or is it fine to keep exposing event handling from Drawing?
There are probably even more questions than this, but this is a good starting point for discussion. Thoughts are welcome, but please keep in mind the audience for this crate.
After the rewrite in #173, the entire events API was overhauled and also made unstable. There are a number of fundamental questions that need to be answered about the events API before we can settle on a stable version of it. This issue is meant to serve as a place to discuss that.
Please keep in mind that the turtle crate is designed for people who are still learning Rust. The goal is not to have the most state of the art event model or to even have the most robust set of events. We want something that will set people up to be able to write interesting programs and we want to avoid teaching them any bad habits that might affect their ability to learn other crates in the future. The final event API we come up with will hopefully be quite simple and easy to teach overall.
Questions
poll_eventmethod or replace it with a blocking/non-blocking pair callednext_eventandtry_next_event?EventLoop::runinglutinor is it important to give the user the ability to structure the loop themselves?Nonefromnext_eventor should there be a specific event for when there will no events anymore? How should all of that look?process::exitwhen the window was closedEventenum? Right now we have a small set of events but there are definitely a lot more we can/should provideEventenum? (e.g.MouseButtonPressed/MouseButtonReleasedvs.MouseButton {pressed: bool}vs. other alternatives)Esckey being pressed and prevent the window from being closed? How would that get implemented?EventLoopstruct? Or is it fine to keep exposing event handling fromDrawing?There are probably even more questions than this, but this is a good starting point for discussion. Thoughts are welcome, but please keep in mind the audience for this crate.