Malte Langkabel
7327343b2a
The dialogs were OS windows with a dim widget behind them, which is why a click beside one could not reach them: Qt drops mouse events for a window a modal blocks, so the dim -- a child of the game window -- never sees the press that REQ-UI-DIALOG-DISMISS now asks it to act on. REQ-UI-MODAL-CHROME states the rule the fix follows: a modal is drawn by the game on the dim, with no title bar, no window border, no window-manager close, and no way for the player to move it, resize it, or drag it off the window. Each draws its own header, as the blueprint selection dialog already does; content too large for the window scrolls inside the modal instead of hanging past the edge. The exception is failure reporting -- a config or blueprint file that will not load is still a system message box, since it must reach the player when there is nothing left to draw on. The requirements that described the old chrome follow: the blueprint dialog loses its window-manager close, the escape menu, game-over and win screens and both name dialogs say they are drawn, and REQ-UI-MODAL-DIM says the dim is the surface a modal sits on rather than a layer kept in step with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x