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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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