Touch and pen
Standard widgets use the framework pointer and gesture system for mouse, touch, and stylus input. Custom widgets should use the same event context rather than track a global mouse position.
Minimal example
This helper can be called from a pointer handler:
#![allow(unused)] fn main() { use teksilo::prelude::*; fn inspect_pointer(ctx: &EventContext) { let kind = ctx.pointer_kind(); let position = ctx.pointer_position(); println!("{kind:?} at {position:?}"); } }
pointer_position() is optional and uses window-logical coordinates;
ctx.to_local(p) converts a window-logical point into the handler's own space.
pointer() provides the current pointer identity and axes. Outside pointer,
scroll, gesture, or drag dispatch, the context uses fallback pointer information;
do not interpret that fallback as a new physical sample.
Common operations
- Use activation handlers for buttons. A direct-pointer press can become a pan or be cancelled before activation.
- Use
pointer_kind()to distinguish coarse input from mouse input. - Use
owns_pointer()when handling moves during a captured interaction. - Handle
PointerCancelas terminal: clear drag, pressed, and preview state. - Use
coalesced()before the current sample when every stylus position matters. These samples also use window-logical coordinates; convert each withctx.to_local. - Use
scroll_source()andscroll_phase()to distinguish wheel input, touch panning, and trackpad momentum. - Provide a press or keyboard route for controls otherwise exposed only on hover.
Related guides
| Task | Guide |
|---|---|
| Implement a custom control | Pointer contract |
| Attach handlers or recognizers | Events and gestures |
| Choose target sizes | Density and targets |
| Implement scrolling | Kinetic scrolling |
| Edit text with a finger | Touch text editing |
| Draw with a stylus | Ink |
| Support an on-screen keyboard | Soft keyboard |
Constraints
Touch and pen capabilities vary by backend, device, and compositor. A finger does not generate hover. Stylus pressure, tilt, proximity, and batched samples must be treated as capabilities, not universal inputs.
The current Wayland integration cannot initiate native window movement with a touch serial. Test custom window chrome on the target compositor. Hardware verification is still required for touch, stylus, trackpad, and screen reader combinations; headless tests do not establish device support.
Reference
Engineering reference
Implementation details and review history are retained in the repository.