Allow the window title to change, and the close to be cancelled

[matt-edmondson]

Two small additions to ImGui.App, both needed by any application that edits documents. They came up building the Schema editor (ktsu-dev/Schema#116), where two acceptance criteria couldn't be met against 3.14.1 — but nothing about them is specific to that app.

Three commits, each self-contained: the feature, an iOS build fix, and the tests that closed a coverage gap.

ImGuiApp.SetWindowTitle(string)

ImGuiAppConfig.Title is init-only and read once when the window is created, so it can't carry anything that changes — the open document's name, or a dirty marker. SetWindowTitle sets it while the application runs.

• Marshals through the Invoker, so it's safe from any thread.
• Skips the write when the title is unchanged, so it's safe to call every frame from OnRender rather than requiring the caller to track the last value.
• ImGuiApp.WindowTitle reads it back, falling back to Config.Title before the window exists.

ImGuiAppConfig.OnClosing

A Func<bool> consulted before the window closes; returning false cancels it.

Cancelling clears IWindow.IsClosing, which the windowing backend re-reads each iteration of the run loop — so this works on every platform, unlike HideOnClose, which intercepts WM_CLOSE by subclassing the native window and is Windows-only.

Three things worth a reviewer's attention:

The check runs before any teardown, and that ordering is the point. The existing Closing handler frees the pinned font data, the ImGui controller, the input context and the GL context. None of that is reversible, so consulting the callback afterwards would leave a cancelled close rendering into a released context.

It fires for every close, including ImGuiApp.Stop. So a handler that unconditionally returns false makes the application impossible to exit. I documented that rather than special-casing Stop, because Stop is precisely how an application confirms an exit it previously vetoed — exempting it would break the flow the callback exists for.

A modal prompt can't be drawn from the callback, since it returns before the next frame is rendered. The documented pattern is: set a flag, return false, draw the prompt from OnRender, call Stop when the user confirms. Worth stating explicitly — it's the first thing someone will try.

When HideOnClose is also set, the close button is intercepted before Closing is reached and the window is hidden instead, so OnClosing isn't consulted on that path. Also documented.

iOS

The first push failed Build net10.0-ios (macOS) with CS1574: the <see cref> to SetWindowTitle in ImGuiAppConfig's docs couldn't resolve, because ImGuiAppConfig.cs compiles for iOS while ImGuiApp.cs is excluded from that target.

Fixed where the repo already handles this rather than by weakening the doc comment. Platform/iOS/ImGuiApp.iOS.NoOps.cs exists to keep desktop window APIs on the iOS surface with matching signatures — its own header says "so cross-platform consumer code compiles unchanged" — each logging a one-time warning. SetWindowTitle now sits there alongside Show, Hide and SetWindowIcon; iOS has no title bar. WindowTitle goes with it, returning Config.Title without warning, since reading back what was configured is an honest answer rather than a no-op.

OnClosing needs no iOS gating: it's a Func<bool> with no Silk.NET coupling, and HideOnClose — just as desktop-only in effect — is ungated in the same file. Only the two members naming Silk.NET types sit behind #if !IOS.

Verification

343 tests pass (330 before), and every new executable line in ImGuiApp.cs and ImGuiAppConfig.cs is covered — verified locally with a cobertura run mapped onto the diff, and SonarCloud reports 100% coverage on new code.

The 13 new tests drive the mocked IWindow:

• the title changes and is reported back through WindowTitle
• an unchanged title is not written through — the every-frame guarantee
• null is rejected
• a call before the window exists is ignored, and the configured title is reported instead
• a queued title write is dropped rather than faulting when the window goes away first
• a close proceeds with no handler, and with one that allows it
• a declined close returns false and clears IsClosing — the two halves of the cancel
• the handler is consulted exactly once per close
• a declined close can be followed by an accepted one — the prompt-then-confirm sequence an editor actually performs
• a cancelled close skips teardown, an allowed close performs it — asserted on currentPinnedFontData, which the Closing handler clears

Two notes on how those last ones are written, since both involved a false start:

The teardown pair needed a way to raise Closing alone; SimulateWindowLifecycle runs the whole lifecycle and unregisters the handlers. TestHelpers.SimulateClosing does just the one event. (Named Simulate… to match the existing helper — Raise… trips CA1030.)

The dropped-write guard is reached only off the window thread, since the Invoker runs work inline for its own thread. Staging that race in a test deadlocks: owning the Invoker from another thread makes Invoke block the caller until that thread pumps, leaving no window in which to null the field. ApplyWindowTitle is therefore internal and called directly under the same precondition — same code, deterministic, and clearer about what the guard is for. Its remarks record why the check isn't redundant with the one in SetWindowTitle.

TestHelpers.CreateMockWindow gains a SetupProperty for Title; it already had one for IsClosing.

No demo change: this is application-lifecycle API rather than a widget, and I kept the diff minimal.

🤖 Generated with Claude Code

https://claude.ai/code/session_012WmzGm9XniSoqaiVGDT6qT

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud