I think there should be standardized types for keyboard, mouse and touch input inside the core and std libraries.
While the types may not be useful on their own (e.g, Duration in core), these types can prove very useful in uniting efforts across libraries and codebases.
A few things that should be implemented for this new core::input module I believe may be:
- Mouse click enums (Left click, right click, middle click, auxiliary mouse buttons (i.e side buttons))
- Mouse click events (Mouse down, mouse up, mouse held)
- Mouse position (a pair of f64 values from 0.0 to 1.0)
- Touch position (a pair of f64 values, 0.0 to 1.0)
- Touch events (finger down, finger up, finger held)
- Keyboard key enums (keys pressed)
- Keyboard click events (Key down, key up, key held)
- Potentially types to handle input from gyroscopes? (potentially useful for embedded systems/phones)
I imagine touch/mouse inputs should also include a to_grid_position(screen_width: usize, screen_height: usize) -> (usize, usize), that take the floating point number and convert it into a pixel position on the screen based on its width and height.
Implementing these, however, would also imply that the std library may be due to include methods to handle input as well since the std library includes methods that use the core::time module types meaningfully.
A few considerations:
- A
std::inputis not exactly guaranteed to work in every tier-1 environment; especially Linux. How do you account for different compositing systems? It may not necessarily be up to the stdlib to handle input directly, but it should handle the types that facilitate it. - Input may be far too diverse for it to be included in the
corelib. I believe that we should still account for the most popular forms of input regardless, and perhaps include more generic input types.
About generic input types:
We could have an n-dimensional input type, defined sort of like this:
/// N-dimensional input
struct InputNd<const N: usize, T: (Unit of measurement, like degrees, pixels, Duration or perhaps physical units?)>([T; N])
type Input2D<T> = InputNd<2, T>;
type Input3D<T> = InputNd<3, T>;
We could then potentially implement more generic methods for this N-dimensional input type; it would also provide a type that libraries for the more niche input methods can then expose so that more interoperability may be achieved; if we are to go down this route though, I think the core library might need to also include types of physical measurements like degrees, pixels and centimeters so as to not render this useless by having libraries export their own types instead of core/std ones.
Overall, the real goal of this is to enable greater co-operation between input libraries. I believe input is a common enough use-case to the point where the inclusion of this within the stdlib is not a far-fetched nor niche idea.