Expose additional winit input events

[hecrj]

Right now, Coffee only exposes three input events (keyboard input, mouse input, and mouse movement).

We should probably expose additional useful events like CursorLeft, CursorEntered, MouseWheel, etc.

[jalbert-dev]

May as well take a look at this one! I've got winit::WindowEvent::ReceivedCharacter exposed as input::Event::TextInput (both using char internally to store the UTF codepoint), and it looks like that works as expected for a few different languages/IMEs. (Hopefully there are no bugs lurking in winit on other platforms or something.)

It looks like the plan here is to expose only peripheral input events to Game::on_input, right? Things like window focus would probably be expected to be exposed to the user so the game can automatically pause on Alt+Tab, etc. Would you want that to be passed to on_input, or did you have another plan in mind for that type of event?

I could also write a small program for the examples directory just to print input events to the screen since I'm going to be testing things anyway (although this is fairly simple, so it probably doesn't really need intense testing). Not sure if you want to invest time in examples right now when the API is subject to change and all that, so that's up to you.

I'll work on getting more of these out of the way, starting with the ones you mentioned.

[hecrj]

May as well take a look at this one!

🎉

I've got winit::WindowEvent::ReceivedCharacter exposed as input::Event::TextInput (both using char internally to store the UTF codepoint), and it looks like that works as expected for a few different languages/IMEs. (Hopefully there are no bugs lurking in winit on other platforms or something.)

Sounds great!

Things like window focus would probably be expected to be exposed to the user so the game can automatically pause on Alt+Tab, etc. Would you want that to be passed to on_input, or did you have another plan in mind for that type of event?

Interesting! Maybe we should keep track of that internally in the Window type and expose an is_focused method. Currently, we are doing something similar with window resizes.

On the other hand, I think it is a good idea to notify window events to the game. Maybe a game needs to redraw some Canvas on resize, or reload something once it gains focus...

I think we need use case data, so let's keep it simple for now. Let's make these kinds of events an input::Event and pass them to on_input, exactly as you mentioned. Then, in the future, we may see some patterns arise when folks use the engine. We can redesign then based on those use cases. Sounds good?

[hecrj]

I could also write a small program for the examples directory just to print input events to the screen since I'm going to be testing things anyway (although this is fairly simple, so it probably doesn't really need intense testing). Not sure if you want to invest time in examples right now when the API is subject to change and all that, so that's up to you.

I forgot about this! It would be great to have that kind of program! However, I would keep the examples directory for interesting applications/games/simulations. Could this simple program you mention be some kind of manual integration test living in the (still non-existent) tests directory?

[hecrj]

After thinking about it a bit more... I think simple programs can also help folks to get started with the engine, which is really valuable. Let's forget about the integration test stuff for now and add it as an example.

[hecrj]

Fixed by #15.

If anyone needs some additional event, open a new issue describing your use case!