Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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 PointerCancel as 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 with ctx.to_local.
  • Use scroll_source() and scroll_phase() to distinguish wheel input, touch panning, and trackpad momentum.
  • Provide a press or keyboard route for controls otherwise exposed only on hover.
TaskGuide
Implement a custom controlPointer contract
Attach handlers or recognizersEvents and gestures
Choose target sizesDensity and targets
Implement scrollingKinetic scrolling
Edit text with a fingerTouch text editing
Draw with a stylusInk
Support an on-screen keyboardSoft 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.