TUI.App --interactive demo's advertised keyboard controls (arrows/Space/R/T) do nothing — InteractiveDemo.HandleInput is unreachable

[matt-edmondson]

What's wrong

InteractiveDemo.CreateInstructionsPanel() (TUI.App/InteractiveDemo.cs) tells the user "↑/↓ - Increment/Decrement Counter", "SPACE - Add +10", "R - Reset", "T - Toggle Theme". But the real input path is UIApplication.ProcessInputAsync (TUI.Core/Services/UIApplication.cs:232) → IUIElement.HandleInput → OnHandleInput, and none of the shipped element types (TextElement, BorderElement, StackPanel, UIElementBase) override OnHandleInput — it defaults to return false (UIElementBase.cs:113). InteractiveDemo.HandleInput(string key) (lines 156-194) — the only code that actually updates _counter/_statusText/theme — is a standalone public static method with exactly one reference in the whole assembly: its own definition. Nothing in Program.cs or InteractiveDemo.RunAsync() calls it.

Failure scenario

Running dotnet run --project TUI.App -- --interactive and pressing any of the keys advertised in the on-screen instructions panel visibly does nothing.

Suggested fix

Either wire real key input into InteractiveDemo.HandleInput (e.g. have UIApplication expose a hook, or give the root element a custom OnHandleInput override that dispatches to it), or remove the unused method and the false claims in the instructions panel.

Acceptance criteria

Pressing an advertised key while running the interactive demo visibly updates the counter/status/theme as documented, or the misleading instructions panel is removed.

[matt-edmondson]

Triage

Category: Bug
Priority: Medium
Area: TUI.App — InteractiveDemo, and the UIApplication input dispatch path it depends on

Medium: no library consumer is broken, but the demo is the shop window for this library, and every advertised key does nothing. Someone evaluating ktsu.TUI runs the interactive demo first, presses the keys the on-screen panel tells them to press, and concludes input handling doesn't work. That is a worse outcome than the demo not claiming the feature at all.

The diagnosis is conclusive rather than suspected — InteractiveDemo.HandleInput has exactly one reference in the assembly, its own definition, and no shipped element type overrides OnHandleInput, which defaults to return false.

The two options in the body are not equivalent. Removing the instructions panel makes the demo honest in an afternoon; wiring input through properly is the real fix but exposes a genuine gap — there is currently no way for application code to receive a key at all, since UIElementBase.OnHandleInput returning false is the only path and nothing overrides it. That is a library design question (does UIApplication expose a hook, or does the demo supply a custom root element?), not demo cleanup.

Sequencing: this sits in the same UIApplication cluster as the repo's other input/render issues and touches ProcessInputAsync. #117 (for #110) is open against that same method — worth landing that first and rebasing on it, rather than resolving a conflict in the input loop.

Suggested assignment: whoever owns TUI.Core's input path — this is not purely a TUI.App change if the real fix is taken.

Duplicates: none. Independent of #116 in this repo, which is a colour-validation bug in TextStyle.
Open PR covering this: none directly.

Suggested next step: decide which of the two options is in scope before starting. If the answer is "not now", remove the false claims from the instructions panel as a stopgap and keep this issue open for the input hook — a demo that promises less is better than one that promises wrongly.

---

Generated by Claude Code