Touch or not?

[overheat]

I saw the closing comment in this issue: #115

“Beyond the scope of mousefood — or even ratatui — as input handling is intentionally left to the user and/or third-party libraries.”

I’m not an expert in this area, but I find this design choice quite interesting and worth exploring further.

From my understanding, this implies a clear separation between rendering (UI) and input handling, which gives users more flexibility but also shifts complexity to the application layer. I’m curious how others approach this in practice.

• Are there recommended Rust crates or patterns for handling input (keyboard, mouse, touch) in a way that integrates well with ratatui?
• For embedded scenarios (e.g., ESP32-P4 with a touchscreen), what would a more “Rust-native” architecture look like?
• Is there any existing ecosystem work that bridges terminal-style UI frameworks with touch input abstractions?

I’ve been thinking along similar lines: if the target device is a touchscreen-based dev board (e.g., ESP32-P4), would it make more sense to:

• Introduce a lower-level unified abstraction for input events (e.g., mapping touch / gestures into mouse-like events)?
• Or design a touch-first UI interaction model from the ground up, instead of inheriting terminal-style paradigms?

Any pointers, examples, or prior art would be very helpful.

[j-g00da]

In terminal scenarios you generally use the terminal manipulation library used by a backend, so if you use ratatui-crossterm as a rendering backend, then you would use crossterm for input handling. There were some attempts in making a common interface for input handling: terminput and tui-input, can't say much about these as I haven't used them myself.

In embedded world it's a bit harder topic, as every mcu and touch driver do whatever they want, there's
https://crates.io/crates/embedded-touch which provides some abstractions, but it looks like there are no driver libraries, so in the end user would be left with having to implement a driver trait on their own - probably still better than nothing.

Maybe it makes sense to create some kind of integration like mousefood-touch, not sure. (cc: @orhun, wdyt?) Either way if we wanted to have a unified abstraction across both terminal and embedded, this would require implementing some kind of screen keyboard (which is absolutely beyond the scope).

[orhun]

I think it would be definitely great to support touch inside of mousefood 👍🏼