Skip to content

[P2-29] Add terminal-native Animation, Transaction, and TimelineView semantics #34

Description

@phranck

Problem

TUIkit has ad hoc pulse, cursor, spinner, and notification timing but no SwiftUI-compatible Animation, Transaction, transition, or TimelineView model. This prevents callers from controlling state-change timing consistently and encourages per-control task loops.

Pixel interpolation does not map directly to a TUI, but transaction semantics, discrete frame timelines, reduced-motion policy, and lifecycle-aware scheduling do.

Proposed solution

  • Add applicable Animation and Transaction APIs with terminal-adapted discrete interpolation and explicit unsupported cases.
  • Propagate transactions through Binding, State, modifiers, and committed render updates.
  • Add TimelineView schedules on the centralized visible-only scheduler.
  • Define terminal-native transitions that operate on cells/layout without raster-only effects.
  • Add Environment policy for reduced/disabled animation and deterministic testing.

Acceptance criteria

  • SwiftUI-shaped animation/transaction/timeline snippets compile for the supported subset under Swift 6.0.
  • Transactions reach binding mutations and exactly one committed frame sequence.
  • TimelineView registers only while committed/visible and produces no idle wakeups after removal.
  • Fake-clock tests make frame sequences deterministic on macOS and Linux.
  • Unsupported raster/GPU animation APIs are explicitly classified in the compatibility manifest.
  • Build, tests, lint, and DocC complete with zero diagnostics.

Dependencies

Depends on data flow #18, render transaction #13, event loop #9, cache liveness #14, and visible-only scheduler #26.

Parallelization

Public API/transaction propagation can start beside scheduler integration after the common clock and committed-effect contracts are stable.

Commit structure

  • Split this issue into small, thematic, independently revertible commits wherever the work can remain coherent.
  • Every commit must build and keep its applicable tests/gates green. Do not commit an intentionally failing regression test; use local/known-issue characterization or land the test with the smallest fix.
  • Keep characterization/fixtures, mechanical renames or moves, semantic changes, and documentation/migration updates separate when each step remains green.
  • The issue boundary is not a commit boundary; multiple commits are expected for independently reversible changes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpriority: mediumImportant follow-up after critical and high dependencies

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions