`core` and `std` types for input?

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::input is 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 core lib. 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.

Duration is in core just because it doesn't depend on os APIs. In std Duration is used concretely both for time measuring (e.g. Instant::elapsed) and timeouts (e.g. in TcpStream::connect_timeout).

1 Like

Yes, that is why I specified specifically within core; in core, it does not serve a direct purpose, but no_std libraries like HAL crates depend on core::Duration for thread-related tasks. core::Duration seems to serve no purpose on its own, but its actually vital for providing a stronger ecosystem.

How portable would this be? I could imagine a platform using ints for these instead of floats, for example. Especially if there is no hardware float op support

Well, if f32 is part of core, which means that f64/f32 should be available in every environment Rust can run on. Embedded platforms choosing not to use f64/f32 in favour of integers due to soft_floats being slow may be solvable using the more generic Input2D.

I think I'd say two things:

  1. Separate from anything else, I don't see how this is going to make meaningful traction for getting into std without it existing in some form in the ecosystem first. Just designing a bunch of types and slapping them into std is definitely not the way to go. Don't start by proposing these types be in std. Start by actually building the crate with these types and getting stakeholders to buy into it. If they don't, then why don't they?
  2. Why does this need to be in std in the first place? Why can't it live in a separate crate indefinitely? This just seems like a pretty weird and oddly specific thing to put into std. And moreover, this also seems like something that should be given the freedom to evolve with potential breaking changes. If so, then std is the wrong place for that kind of evolution.