slider: Let a touch drag on the track move the thumb

[Bombatomica64]

Description

Thank you for GPUI Kit, and for making it usable on mobile at all. While testing every Kit 0.7.0 component on Android (through gpui-mobile), I found two small problems with clear fixes, so I'm proposing them here. Each is a separate commit, and I'm happy to split them into separate PRs, change the approach, or drop either one if it doesn't fit how you want to handle touch. The remaining findings are collected in #3310.

1. Slider: a touch drag on the track moves the thumb

On touch platforms (gpui-mobile on Android/iOS), a finger on the slider track could not move the thumb: GPUI delivers a finger drag as TouchDragEvent (when a handler claims it with window.prevent_default() on Started) or as scrolling, while on_drag drag-and-drop only reacts to the mouse. Dragging a slider scrolled the page instead.

SliderTrack now adds an absolutely positioned canvas layer (only when not disabled) that claims touch drags starting on the track and feeds them through the existing update_value_by_position / handle_release path, so SliderEvent::Change and SliderEvent::Release fire as for the mouse. For range sliders the thumb nearer to the touch start moves. Drags already claimed by another handler are left alone, and mouse behaviour is unchanged.

2. fps: use Droid Sans Mono on Android

On Android, the first render of FpsMonitor panics: DEFAULT_FONT falls through to "monospace", which Android's cosmic-text backend does not resolve as an alias. None of GPUI's desktop fallbacks exist there either, so font resolution fails. iOS already has its own branch for the same reason.

This adds an Android branch that uses Droid Sans Mono, a family every Android system image ships (/system/fonts/DroidSansMono.ttf).

Screenshot

Slider: behavioural change, no visual difference. fps: before, the app aborts with failed to resolve font 'monospace' or any of the fallbacks when the HUD first paints; after, the HUD renders.

How to Test

• New test slider_touch_drag_moves_the_actual_thumb in crates/kit/tests/disclosure.rs dispatches TouchDragEvent Started/Moved/Ended and checks the thumb follows in both directions. It fails without the change (assertion failed: after.center().x > before.center().x) and passes with it.
• disabled_slider_ignores_pointer_changes now also checks that a touch drag leaves a disabled slider alone.
• cargo test -p gpui-kit --features test-support,component --test disclosure: 6 passed.
• On device: the same change, as a patch on Kit 0.7.0, in an Android test app (gpui-mobile host path, Android 13 emulator via Redroid). Horizontal, vertical and range sliders follow the finger.
• cargo check -p gpui-fps and cargo fmt --check pass on Linux (non-Android targets compile the same code as before).
• FPS HUD on device: the same Android test app renders the HUD instead of panicking.

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate.
• Passed cargo run for story tests related to the changes. (Not run; the slider is covered by the test above, the fps change is an Android-only cfg.)
• Tested macOS, Windows and Linux platforms performance (if the change is platform-specific) — desktop mouse path and desktop font constants unchanged; touch and Android paths tested on Android.

Playground used for the on-device testing: Bombatomica64/Gpui-android (prebuilt APK), in case you want to try these changes on Android.

Thanks for taking the time to review this.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.