35 lines
1.8 KiB
Markdown
35 lines
1.8 KiB
Markdown
# 11 — UI-Gerüst und Screen-Modell
|
|
|
|
Type: grilling
|
|
Status: open
|
|
Blocked by: —
|
|
|
|
## Question
|
|
|
|
Wie sieht das konkrete Screen-Modell aus, das auf der Empfehlung aus 06 aufsetzt?
|
|
|
|
Ticket 06 hat die Fakten geliefert und Screen-Stack über zentralem `Game`-State empfohlen. Die
|
|
Entscheidungen darüber stehen noch aus:
|
|
|
|
- **Ein Stack oder zwei?** `Vec<Screen>` für Screens und Popups gemeinsam (sxtetris), oder getrennt als
|
|
`current_page` plus `Option<Popup>` (chess-tui)? Einer ist einfacher, zwei sind klarer bei
|
|
Popup-über-Popup.
|
|
- **Wo lebt der Listen- und Tabellen-State?** `ListState` gehört nach ratatui-Logik in die UI. Wird er
|
|
beim `pop()` verworfen oder aufbewahrt — steht der Cursor beim Zurückkehren ins Inventar wieder oben?
|
|
- **`KeyEventKind::Press` allein oder auch `Repeat`?** Rundenbasiert spricht für nur `Press`, aber ein
|
|
Grid, das man Feld für Feld antippt, fühlt sich zäh an. UX-Entscheidung, keine technische.
|
|
- **Bleibt `game/` wirklich ratatui-frei?** Sobald Effekte Farben oder Symbole aus TOML mitbringen
|
|
(Ticket 01, 02), ist die Versuchung groß, `Color` nach `game/` zu ziehen. Alternative: eigene Farb- und
|
|
Symboltypen in `data/`, Übersetzung in `ui/theme.rs`.
|
|
- **Welche Screens gibt es zum Start**, und welche Aktionen kennt `Game::apply(Action)`?
|
|
|
|
Ergebnis: Screen-Enum, Stack-Modell, Action-Liste und die Regel, was `game/` nicht importieren darf.
|
|
|
|
## Vorgaben aus anderen Tickets
|
|
|
|
- **02**: Charakterbogen und Charakterbau sind Registry-Schleifen, keine gemauerten Layouts —
|
|
Begründung in [Ticket 02](02-typ-registry.md).
|
|
- **04**: Der Startbildschirm trägt eine Zeile mit Warnungsanzahl und Logdateiname
|
|
(„12 Ladewarnungen — `logs/load-20260812-112305.log`"). **Eine Zeile, kein Screen** — der Inhalt
|
|
gehört in einen Texteditor, nicht in ein TUI mit Scrolling und Navigation.
|