Add TUI API surface to AppContext under tui#12633
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
e30ebf4 to
f85df3c
Compare
7eb80a2 to
cb839d6
Compare
f85df3c to
f02f2af
Compare
cb839d6 to
68de666
Compare
f02f2af to
73c3649
Compare
68de666 to
daa83ce
Compare
73c3649 to
c459ffb
Compare
daa83ce to
21e266f
Compare
21e266f to
2f3a0e9
Compare
c459ffb to
878719b
Compare
878719b to
b0ddbff
Compare
2f3a0e9 to
a2e8bfc
Compare
b0ddbff to
4d98812
Compare
4cfc5f6 to
898f32e
Compare
tui
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
…ain (#12413) ## Description First PR in a stack that adds an optional TUI backend to `warpui`. This PR is **only** the backend-neutral groundwork — no TUI code, no behavioral change. Today the view responder chain (focus/blur, action dispatch, ancestor walks) is derived from the **GUI presenter's** layout-time parent map. This PR moves that ownership into `AppContext` so any backend can drive it: - New `AppContext.view_parents` — a per-window child→parent view map. - Fed from two sources: creation-time structural parentage (`record_view_parent`) and the active backend's render pass (`report_view_embeddings`). - Walked by `view_ancestors` / `view_parent_map`; all responder-chain / focus / dispatch sites now read this map instead of `presenter.ancestors()`. - The GUI presenter is updated to feed `report_view_embeddings`, so GUI behavior is unchanged. This is a behavior-preserving, GUI-only refactor. The TUI presenter feeds the same map later in the stack (#12601). **Reviewing (3 files):** `app.rs` is the substance — the map, its accessors, and the call-site swaps. `presenter.rs` wires the GUI render pass to report embeddings. The test swaps `presenter.ancestors()` → `ctx.view_ancestors()`. ## Stack `master` → **#12413 (this)** → #12633 → #12634 → #12601 ## Testing - [x] `cargo check -p warpui_core -p warp -p warpui` clean; `cargo nextest -p warpui_core` 279 passed / 7 skipped. - No manual run: no behavioral change. ## Agent Mode - [x] Warp Agent Mode CHANGELOG-NONE --------- Co-authored-by: Oz <oz-agent@warp.dev>
…he additive tui feature Adds the shared-registry seam for a TuiView (StoredView::Tui in window.rs, TuiView/AnyTuiView, the AppContext add_tui_* / render_tui_view helpers, and the ViewContext add_tui_view hooks), the TuiElement trait + TuiEmpty + TuiPresentationContext, and the primitive submodules (geometry, buffer, event). Relaxes the shared view bounds (View -> Entity/'static), splits the unbounded ViewHandle accessors, and hoists the shared invalidation helper so a second view trait can flow through the existing paths. The tui cargo feature and its crossterm/unicode-* optional deps relocate here from the foundation. Runtime-drained event.rs methods/fields and TuiPresentationContext::new carry a scoped #[allow(dead_code)] (removed in the runtime slice). Co-Authored-By: Oz <oz-agent@warp.dev>
5712979 to
54d124c
Compare
There was a problem hiding this comment.
Overview
This PR adds a feature-gated TUI API surface in warpui_core, including TUI view storage/rendering hooks, shared StoredView dispatch paths, TUI event/presentation context types, terminal-cell geometry and buffer primitives, and tests for the additive TUI behavior.
Concerns
- No blocking correctness, security, or spec-drift concerns found in the annotated diff.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
vorporeal
left a comment
There was a problem hiding this comment.
yeah sure seems fine, and if it isn't, you'll ask me to approve another PR :P
There was a problem hiding this comment.
one high-level question: do we want the Tui prefix everywhere? can we drop it, and in contexts where we're referencing gui and tui variants of the same type, use tui::MyType and gui::MyType partially-qualified names?
There was a problem hiding this comment.
I don't think it particularly matters all that much, except that without the prefix, there might be inconsistent qualifying, and in any case where it is not partially qualified it will take a scroll (or a file read tool call to look at the use statement) to disambiguate, and other than aesthetics I don't think really much of an advantage
| origin_view_id: Option<EntityId>, | ||
| } | ||
|
|
||
| #[allow(dead_code)] |
There was a problem hiding this comment.
why the #[allow(dead_code)]? transient due to it being dead until some future PR in the stack? if so, prefer using expect(dead_code) instead of allow(dead_code), as then you'll get a compilation error when it's no longer dead, and remove it (so it doesn't become stale).
not blocking; goal is more to share the gospel of expect() vs. allow() than to ask for changes :)
| /// nothing — only container/child-view elements override this). | ||
| /// - [`dispatch_event`](TuiElement::dispatch_event): offer an event to this | ||
| /// element, returning whether it was handled (default: not handled). | ||
| pub trait TuiElement { |
There was a problem hiding this comment.
I think the actual shape of this interface is definitely subject to churn
There was a problem hiding this comment.
I don't think it particularly matters all that much, except that without the prefix, there might be inconsistent qualifying, and in any case where it is not partially qualified it will take a scroll (or a file read tool call to look at the use statement) to disambiguate, and other than aesthetics I don't think really much of an advantage

Description
tuicargo feature flagTuiElementinterface which diverges from guiElementViewtraits and APIs; these depend onTuiElementAnyView to wrapper "router"StoredViewenum which delegates toAnyView/AnyTuiView` wrapperTuipresenter types - event context, presentation contextStack
#12413 → #12633 (this) → #12634 → #12601
Testing
cargo check -p warpui_core -p warp -p warpuiclean in both default and--features tui.cargo nextest -p warpui_core: 286/7 (default), 311/7 (--features tui).Agent Mode
CHANGELOG-NONE