TUI build broken: quadraui bumped ratatui 0.29->0.30 (Frame/Buffer/Rect split into ratatui-core), vimcode's tui_main still on 0.29 types (~46 errors, 4 files)

[JDonaghy]

Summary

quadraui develop bumped its ratatui dependency from 0.29 to 0.30 at some point between commit ebb4ab7 and the current tip (unrelated to #445 or #452 — discovered as a side effect of validating those). ratatui 0.30 split Frame/Buffer/Rect out into a new ratatui-core crate. quadraui::tui::Backend::enter_frame_scope (and the rest of quadraui's TUI backend surface) now speaks ratatui-core types.

vimcode's own Cargo.toml pins ratatui = "0.29" directly, and src/tui_main/ calls into quadraui's backend using ratatui 0.29 types (e.g. backend.enter_frame_scope(frame, ...) where frame: ratatui::Frame). Cargo resolves both ratatui 0.29 (vimcode's direct dep) and ratatui 0.30 + ratatui-core (quadraui's dep) side by side as distinct crates, so the build fails at type-checking with E0308 everywhere vimcode's ratatui-0.29 types cross the boundary into quadraui's ratatui-core-based API:

error[E0308]: mismatched types
    --> src/tui_main/render_impl.rs:1437:31
     |
1437 |     backend.enter_frame_scope(frame, |b| {
     |             ----------------- ^^^^^ expected `ratatui_core::terminal::frame::Frame<'_>`, found `ratatui::Frame<'_>`
     |
     = note: `ratatui::Frame<'_>` and `ratatui_core::terminal::frame::Frame<'_>` have similar names, but are actually distinct types

Scope

46 distinct errors (per binary target — vimcode builds two: vcd and vimcode), spread across:

• src/tui_main/panels.rs — 36 call sites
• src/tui_main/render_impl.rs — 28 call sites
• src/tui_main/quadraui_tui.rs — 6 call sites
• src/tui_main/mod.rs — 4 call sites

This is a real migration, not a one-line fix: bump vimcode's ratatui pin to 0.30 (or whatever quadraui currently uses) and update every touched call site to use ratatui-core-sourced Frame/Buffer/Rect (either directly, or via whatever re-export quadraui now expects — worth checking whether quadraui re-exports ratatui_core types for consumers, which would be the cleaner fix than vimcode taking a second direct ratatui-core dependency).

Severity

Currently blocks every vimcode build — GTK and TUI both, since vimcode's Cargo.toml always enables quadraui's tui feature (quadraui = { path = "...", features = ["tui", "terminal"] }, unconditional, not gated behind vimcode's own gui/tui top-level features). This was masked until now by two prior blockers in the same dependency-resolution path (#445's accelerator-dispatch gap needed quadraui changes first, then #452's unicode-width conflict prevented cargo from even reaching type-checking). With #452 fixed and vimcode's companion [patch.crates-io] entry added (see vimcode commit 8f47955 on branch issue-587-command-palette-fails-to-open-silently-b), dependency resolution now succeeds and this is the next and only remaining blocker.

Repro

cd vimcode  # with the [patch.crates-io] vt100 entry from commit 8f47955, quadraui path-dep pointing at a quadraui checkout on develop tip
cargo build --features gui --no-default-features
# or
cargo build --features tui --no-default-features

Cross-repo note

Filed while validating vimcode#587 (unrelated bug — command palette). Not attempted as part of that fix: too large a migration to improvise without visual TUI verification available, and clearly out of scope for a targeted bug fix. See coord context show vimcode 587 for the full chain of discoveries (#445 → #452 → this).

[JDonaghy]

Coordinator Assignment

Machine: dellserver
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #590: TUI build broken: quadraui bumped ratatui 0.29->0.30 (Frame/Buffer/Rect split into ratatui-core), vimcode's tui_main still on 0.29 types (~46 errors, 4 files)

Summary

quadraui develop bumped its ratatui dependency from 0.29 to 0.30 at some point between commit ebb4ab7 and the current tip (unrelated to #445 or #452 — discovered as a side effect of validating those). ratatui 0.30 split Frame/Buffer/Rect out into a new ratatui-core crate. quadraui::tui::Backend::enter_frame_scope (and the rest of quadraui's TUI backend surface) now speaks ratatui-core types.

vimcode's own Cargo.toml pins ratatui = "0.29" directly, and src/tui_main/ calls into quadraui's backend using ratatui 0.29 types (e.g. backend.enter_frame_scope(frame, ...) where frame: ratatui::Frame). Cargo resolves both ratatui 0.29 (vimcode's direct dep) and ratatui 0.30 + ratatui-core (quadraui's dep) side by side as distinct crates, so the build fails at type-checking with E0308 everywhere vimcode's ratatui-0.29 types cross the boundary into quadraui's ratatui-core-based API:

error[E0308]: mismatched types
    --> src/tui_main/render_impl.rs:1437:31
     |
1437 |     backend.enter_frame_scope(frame, |b| {
     |             ----------------- ^^^^^ expected `ratatui_core::terminal::frame::Frame<'_>`, found `ratatui::Frame<'_>`
     |
     = note: `ratatui::Frame<'_>` and `ratatui_core::terminal::frame::Frame<'_>` have similar names, but are actually distinct types

Scope

46 distinct errors (per binary target — vimcode builds two: vcd and vimcode), spread across:

• src/tui_main/panels.rs — 36 call sites
• src/tui_main/render_impl.rs — 28 call sites
• src/tui_main/quadraui_tui.rs — 6 call sites
• src/tui_main/mod.rs — 4 call sites

This is a real migration, not a one-line fix: bump vimcode's ratatui pin to 0.30 (or whatever quadraui currently uses) and update every touched call site to use ratatui-core-sourced Frame/Buffer/Rect (either directly, or via whatever re-export quadraui now expects — worth checking whether quadraui re-exports ratatui_core types for consumers, which would be the cleaner fix than vimcode taking a second direct ratatui-core dependency).

Severity

Currently blocks every vimcode build — GTK and TUI both, since vimcode's Cargo.toml always enables quadraui's tui feature (quadraui = { path = "...", features = ["tui", "terminal"] }, unconditional, not gated behind vimcode's own gui/tui top-level features). This was masked until now by two prior blockers in the same dependency-resolution path (#445's accelerator-dispatch gap needed quadraui changes first, then #452's unicode-width conflict prevented cargo from even reaching type-checking). With #452 fixed and vimcode's companion [patch.crates-io] entry added (see vimcode commit 8f47955 on branch issue-587-command-palette-fails-to-open-silently-b), dependency resolution now succeeds and this is the next and only remaining blocker.

Repro

cd vimcode  # with the [patch.crates-io] vt100 entry from commit 8f47955, quadraui path-dep pointing at a quadraui checkout on develop tip
cargo build --features gui --no-default-features
# or
cargo build --features tui --no-default-features

Cross-repo note

Filed while validating vimcode#587 (unrelated bug — command palette). Not attempted as part of that fix: too large a migration to improvise without visual TUI verification available, and clearly out of scope for a targeted bug fix. See coord context show vimcode 587 for the full chain of discoveries (#445 → #452 → this).

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 15m 41s
Log: /home/john/.coord/logs/245191c4ec62.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: elitebook
Status: done
Exit code: 0
Duration: —

Summary

Smoke test passed: GTK + TUI both build clean against ratatui 0.30, binaries start, TUI rendering confirmed visually by operator (no artifact available, built fresh in scratch worktree)

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

ratatui 0.29→0.30 Cargo.toml bump verified sufficient; no tui_main call-site changes needed (ratatui re-exports ratatui-core types)

Verdict: approve

Review findings

Review: #590 — TUI build broken (ratatui 0.29→0.30 mismatch)

Branch: issue-590-tui-build-broken-quadraui-bumped-ratatui
Diff reviewed: origin/develop...origin/issue-590-tui-build-broken-quadraui-bumped-ratatui
Single commit: bb4c058 — "fix(#590): bump ratatui 0.29→0.30 to align with quadraui's dependency"

What changed

Only two files, and the change is genuinely tiny:

• Cargo.toml: ratatui = "0.29" → ratatui = "0.30" (1 line)
• Cargo.lock: regenerated (979 insertions / 99 deletions — mostly new transitive deps pulled in by ratatui 0.30's crate split: ratatui-core, ratatui-widgets, ratatui-crossterm, ratatui-macros, ratatui-termina, ratatui-termwiz, plus ratatui-core's new color-blending deps palette/csscolorparser/euclid/lab/deltae/kasuari)

No changes to src/tui_main/panels.rs, render_impl.rs, quadraui_tui.rs, or mod.rs. I diffed each of these files individually against develop and confirmed zero delta. This directly contradicts the issue body's assumption ("this is a real migration... update every touched call site") — the worker determined the call-site rewrite the issue anticipated wasn't actually necessary, and I independently verified that determination is correct (see below). This is also the right outcome per this repo's Platform-Neutrality Rule — zero backend-specific code was the best possible fix here, not a shortcut.

Verification (static, no build run per reviewer instructions)

I was instructed not to run cargo build/cargo test myself, so I verified correctness by reading the actual dependency graph and crate sources instead of compiling:

1. quadraui's ratatui pin: ~/src/quadraui/quadraui/Cargo.toml:55 → ratatui = { version = "0.30", optional = true }. Same 0.30 line vimcode now uses.
2. Cargo.lock resolves to exactly one ratatui entry (0.30.2) and one ratatui-core entry (0.1.2) — no duplicate/old ratatui 0.29 left anywhere in the graph. (There are unrelated 0.29.x entries for crossterm, nix, and wayland-* — different crates, not a concern.)
3. The actual root cause of the original E0308 errors: the issue's own pasted rustc error — "ratatui::Frame<'_> and ratatui_core::terminal::frame::Frame<'_> have similar names, but are actually distinct types" — is rustc's stock diagnostic for two different semver-incompatible versions of the same crate resolved simultaneously, not evidence of an actual API reshape. Confirmed by reading the cached ratatui-0.30.2 source directly:
   • ratatui-0.30.2/src/lib.rs:479: pub use ratatui_core::terminal::{CompletedFrame, Frame, Terminal, TerminalOptions, Viewport};
   • ratatui-0.30.2/src/lib.rs:480: pub use ratatui_core::{buffer, layout};
   • So ratatui::Frame/ratatui::buffer::Buffer/ratatui::layout::Rect are just re-exports (type aliases) of the ratatui-core types. As long as vimcode and quadraui resolve to the same ratatui-core version (confirmed: both 0.1.2), ratatui::Frame used in tui_main/ and the Frame quadraui's enter_frame_scope expects (~/src/quadraui/quadraui/src/tui/backend.rs:55-56,193-198, which itself imports use ratatui::Frame;, not ratatui_core directly) are the literal same type. No call-site changes needed.
4. Checked ratatui 0.30's default features (ratatui-0.30.2/Cargo.toml.orig:30): default = ["all-widgets", "crossterm", "layout-cache", "macros", "underline-color"] — crossterm is still on by default, so mod.rs's unqualified use ratatui::backend::CrosstermBackend; / use ratatui::crossterm::{...} (unchanged, still present on this branch) keep working without any default-features = false change in Cargo.toml.
5. flatpak/cargo-sources.json was last regenerated at the release 0.10.0 commit and is already stale relative to develop's current Cargo.lock independent of this PR — confirming (per CLAUDE.md's Branching & Releases section) that file is only synced immediately before the develop→main release PR, not on every feature branch. Not a gap introduced here.
6. CI (.github/workflows/ci.yml.disabled) is disabled repo-wide, so there's no automated gate this skips.

One non-blocking nit

The commit message's stated root cause — "ratatui 0.29 exact-pinned unicode-width to =0.2.0, which conflicted with vt100 0.16... ratatui 0.30 relaxes that... so the E0308 errors disappear" — doesn't actually match the mechanism. A unicode-width version conflict would surface as a cargo resolution failure ("failed to select a version"), not the E0308 type-mismatch the issue describes. The real mechanism is straightforwardly "vimcode and quadraui requested semver-incompatible major versions of the same crate, Cargo resolved two copies, rustc reported them as distinct types" — fixed simply by making both request the same 0.30 line, independent of unicode-width. This doesn't affect correctness of the fix (verified independently above), just future debugging clarity if someone reads the commit log later. Not asking for a re-push over this alone — call it out in the PR description if one gets opened, or amend if the branch gets touched again for another reason.

Checklist

• Tests: none added — appropriate; this is a pure dependency-version alignment with no new behavior to test.
• Scope: in scope of TUI build broken: quadraui bumped ratatui 0.29->0.30 (Frame/Buffer/Rect split into ratatui-core), vimcode's tui_main still on 0.29 types (~46 errors, 4 files) #590, and narrower than the issue anticipated (in a good way — verified correct, not a corner cut).
• Security: n/a, dependency version bump only.
• Platform-neutrality (project CLAUDE.md): fully respected — no src/gtk/ or src/tui_main/ edits at all, the fix lives entirely in the shared dependency declaration.
• Follows conventions: plain semver bump, matches style of other deps in Cargo.toml.
• Workflow: branch named correctly (issue-590-...), single focused commit, no PR opened yet (correct — awaiting smoke-test/merge decision per this repo's workflow).

Verdict

Approve. The fix is minimal, correctly scoped, and I verified via the actual ratatui-core re-export mechanism (not just trusting the commit message) that no call-site migration is actually required. Recommend the human still run the actual cargo build --features gui --no-default-features / --features tui --no-default-features smoke test before merging, per this repo's normal pre-merge gate — I did not run a build myself per reviewer instructions, and static analysis, while thorough here, is not a substitute for the real compile.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Branch was already directly on top of origin/develop tip (no rebase needed, no conflicts). Ran full test suite (cargo test --no-default-features) — all passed. verify-merge confirmed develop-ahead=0, no foreign commits. Ran coord merge --repo vimcode: opened PR #591, merged, closed issue #590.