Keep the window title current, and ask before the window closes (#116)

[matt-edmondson]

Finishes #116. The last two acceptance criteria were blocked by ktsu.ImGui.App — ImGuiAppConfig.Title is init-only and read once at window creation, and there was no cancellable close hook. I added both upstream in ktsu-dev/ImGuiApp#341, now released as 3.16.0, which this bumps to.

Live window title

Shows the open document plus a trailing * while it has unsaved changes, refreshed each frame. SetWindowTitle skips the write when the title is unchanged, so that costs a string comparison per frame rather than a window call.

The dirty state comes from the undo service via the existing HasUnsavedChanges — not tracked a second time.

The menu-bar indicator stays. It isn't redundant: a maximised window's title bar is easy to overlook, and a tiling window manager may not draw one at all.

Close prompt

Closing the window now raises the same Save / Discard / Cancel prompt New and Open already use, instead of discarding the work silently.

Three things about the hook are worth a reviewer's attention, because each is a way to get it wrong:

The prompt can't be drawn from the callback — it returns before the next frame is rendered. So a close with unsaved work only records the request and refuses; the next frame raises the prompt, and only the user's answer closes for real.

The callback also fires for ImGuiApp.Stop, which is how the confirmed exit closes. Without the explicit exitConfirmed latch the editor would veto its own agreed exit forever — discarding doesn't clear the unsaved flag, so the condition that refused the first close is still true once the user has said to close anyway. That would have been an unquittable window, and it's the one bug in this change I'd most want caught.

A second close while the prompt is up would otherwise stack another prompt, so the request is latched until the first is answered. WithUnsavedChangesGuard grew an optional onCancel for that — the close path is the only caller that needs to know the user backed out; New and Open simply do nothing.

Why the entry point moved

Adding OnClosing tipped SchemaEditor over the CA1506 class-coupling limit (96, limit 95). I checked what actually cost the point rather than guessing: it's the Func<bool> the assignment introduces.

The honest fix was to take out what doesn't belong. Main and the ImGuiAppConfig now live in SchemaEditor/Program.cs — that configuration names a windowing framework and a delegate type per callback, none of which is part of editing a schema. So the fix follows what the analyser was pointing at rather than suppressing it, and the host's whole contract with ImGuiApp is readable in one place. OnStart, OnTick, OnRender, OnMenu and ShouldClose become internal so the entry point can bind them.

Verification, and its limit

299 tests pass on net8.0, net9.0 and net10.0, and the solution builds against 3.16.0 — which is what proves the released package really carries the new API, rather than my assuming it from the merge.

The editor wiring itself is not covered by any test. SchemaEditor has no tests and no harness to write them against — that's #128. What's verified here is that it compiles and that nothing else regressed; the title updates and the close prompt have not been executed by a test. I'd rather say that plainly than let "299 tests pass" imply more than it does.

That's also the strongest argument yet for #128: this change adds exactly the kind of stateful, sequence-dependent logic (a latch, a deferred prompt, a re-entrancy guard) that a headless harness would catch regressions in. ktsu.ImGui.App ships an ImGui.App.Testing package built for this.

Closes #116

🤖 Generated with Claude Code

https://claude.ai/code/session_012WmzGm9XniSoqaiVGDT6qT

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud