How should the turtle Events API look?

[sunjay]

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.