06 — Research: ratatui-App-Architektur #7
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Teil der Map #1 · Type:
wayfinder:research· Blocked by: —Wie strukturiert man eine ratatui-App mit mehreren Bildschirmen sauber? Fakten sammeln, keine Entscheidung.
Volle Fragestellung (kanonisch):
.scratch/rustkeep-1.0/issues/06-research-ratatui-architektur.mdAnswer — aufgeloest 2026-08-11
Vollstaendiger Bericht im Repo:
.scratch/rustkeep-1.0/research/06-ratatui-architektur.md(942 Zeilen, gegen Live-Quellen geprueft).Vec<Screen>) ueber zentralemGame-State. ratatui empfiehlt offiziell nichts — dokumentiert Elm/Component/Flux neutral, zu Multi-Screen gar keine Seite. Maintainer joshka raet im Forum zum Enum,demo2macht Enum +impl Widget for &App, chess-tui (rundenbasiert) faehrtcurrent_page+current_popup.game/(kennt ratatui nicht),data/,ui/{screen,input,theme,widgets/,screens/}, ein EintrittspunktGame::apply(Action).Clearauf zentriertes Sub-Rectnach dem Screen. Negativbefund: kein produktives Projekt nutztVec<Box<dyn Component>>dafuer, auch gitui nicht.event::read(), kein Tick, kein tokio.Canvastaugt nur fuer Minimap.ratatui::run(...)genuegt, der Hook wird selbst installiert.DropvonTerminalstellt nicht wieder her.KeyEventKind::Press-Filter ist Pflicht, sonst doppelte Zuege. Kitty-Protokoll undEvent::Pastegehen dort gar nicht.Sieben Punkte sind im Bericht als nicht verifiziert markiert. Sechs Anschlussfragen sind zu #12 (UI-Geruest und Screen-Modell) und #13 (Prototyp-Durchstich) graduiert.