# Palm phone webOS motion reference and K230 translation

This is design research for a proposed shell, not proof of its behavior on the K230. The primary historical source is the [Palm Pre User Guide](https://support.bell.ca/_web/guides/User-Guides/Mobile/PalmOne/Palm-EN/palm_pre_userguide_en%28en%29.pdf), reviewed as PDF text on 2026-09-23. The [archived HP webOS Developer Center notification guide](https://www.banneret.nl/webos/documentation/all/dev-guide/mojo/dashboards-notifications.html) describes banners followed by a deferred dashboard; this is a third-party archive of HP documentation, not a live vendor endpoint. No historical motion footage with verifiable frame timestamps was used. The sources provide interaction and spatial behavior, **not measured durations, velocity constants, spring curves, or K230 performance**.

| Phone webOS behavior documented by Palm | Proposed K230 translation | Evidence boundary |
| --- | --- | --- |
| A full app yields to a smaller card; left/right swipes move among cards; tap maximizes; a card follows a held drag and can be thrown upward to close (guide pp. 19–20, 25–26). | A continuous app→card→deck coordinate path; the same live surface shrinks, neighbors remain spatially adjacent, release snaps to a selected card, tap expands from that location, and an upward throw requests close. | Existing Sway card owner proves core live-source/focus lifecycle only at its own gates. This proposal owns coordinated interpolation and transition continuity. |
| Drag scrolls a specific amount; a faster flick scrolls farther; tap or drag stops it (guide p. 20). | Apps, Settings, and History track the finger while held, coast within bounded content after release, then stop at content limits; touching again stops coast and begins a new gesture. | No Palm numeric curve is copied. K230 curve and frame budget require measured physical tuning. |
| Launcher pages are reached by left/right swipe and vertical content movement; hold shows a cue before reordering (guide pp. 24, 26). | Apps uses direct vertical scrolling, horizontal page/section swipe only where pages remain, and a cancellable long press with a visual halo/context sheet. Pages never require Previous/Next as the primary path. | A context action is proposed; no app rearrangement is promised until persistence and conflict policy are implemented. |
| Notifications appear briefly, then remain in a dashboard; tap acts; some can be thrown sideways to dismiss (guide pp. 32–33 and HP guide). | A preview enters near System without moving focused app content; History scrolls vertically and a sideways item swipe reveals a dismiss affordance before a committed dismissal. | Privacy and priority policy from this change still applies. Sideways motion never silently erases history on a mere drag. |

The guide's gesture area was separate hardware. This board has a full touch panel, on-screen keyboard, and persistent shell controls. We translate direction and spatial continuity, not the exact physical gesture strip. A bottom screen region may start app→deck only when the compositor owns that region, the keyboard does not, and a real-finger conflict test passes. The old Windows control remains only in the separately selected rollback session. The app's own vertical/horizontal scroll and text selection win inside app content; the compositor cannot steal them because a finger moved in a similar direction.

Source/board audit for tactile feedback: the installed device tree [`nix/dts/k230-tdisplay.dts`](../../../nix/dts/k230-tdisplay.dts) names panel/touch/backlight but no haptic actuator. The vendor [T-Display K230 V1.0_NEW schematic PDF](https://github.com/Xinyuan-LilyGO/T-Display-K230_canmv_rt/blob/main/schematic/T-Display%20K230_V1.0_NEW.pdf) was downloaded and its eight sheets/text searched for motor/vibration/haptic/buzzer identifiers; none was identified. This negative search is limited by schematic text extraction and board-revision uncertainty. It does **not** prove all revisions lack an actuator. No vibration work is planned for the current board. Press/hold recognition, accepted snap, and close/refusal have complete visual feedback. If supported hardware is discovered later, a separate change can investigate it. Sound or a decorative shake is not haptic feedback.

The final route decision uses the Palm-style live-card deck as Home. A bottom pull from a running app enters that deck; a continued upward pull from the deck reveals the installed-app drawer. The top-edge shade and contextual side-edge shell Back borrow familiar full-screen gesture placement, while [Android developer guidance](https://developer.android.com/develop/ui/views/touch-and-input/gestures/gesturenav) is used solely for edge-conflict comparison. The K230 design does not add an Android home grid or assume universal Back in Wayland apps.