fix(gui): wasVisible-guard setGeometry in three more frameless toggles (#2603)#2635
Conversation
#2603) Follow-up to #2580. PropDashboardDialog, RadioSetupDialog, and PanFloatingWindow all reapplied geometry unconditionally after a flag change in setFramelessMode(), causing the same macOS cold-launch top-left placement bug fixed in the 5 dialogs touched by #2580. Wrap each setGeometry(geom) in `if (wasVisible)` so Qt's normal placement logic (centering on parent, restored last position, etc.) runs on first show, while runtime frameless toggles on already-visible dialogs still preserve geometry. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
#2603) Follow-up to #2580. PropDashboardDialog, RadioSetupDialog, and PanFloatingWindow all reapplied geometry unconditionally after a flag change in setFramelessMode(), causing the same macOS cold-launch top-left placement bug fixed in the 5 dialogs touched by #2580. Wrap each setGeometry(geom) in `if (wasVisible)` so Qt's normal placement logic (centering on parent, restored last position, etc.) runs on first show, while runtime frameless toggles on already-visible dialogs still preserve geometry. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
LGTM — narrowly-scoped follow-up to #2618 that applies the documented frameless-toggle pattern (CLAUDE.md → docs/dialog-patterns.md: "restore geometry only if the window was already visible") to three more setFramelessMode implementations.
Verified against each file:
PanFloatingWindow.cpp:83—wasVisibleis already captured at line 74 and gates the trailingshow()at line 84. Adding the same gate tosetGeometryis the matching half of that pair.PropDashboardDialog.cpp:848—wasVisiblealready captured at line 843; them_titleBar/m_bodyLayoutadjustments below remain unconditional, which is correct (they're chrome-visibility, not window-geometry).RadioSetupDialog.cpp— same shape, same fix.
No out-of-scope changes, no QSettings usage introduced, no RAII or null-pointer concerns. Thanks for the quick follow-up.
ten9876
left a comment
There was a problem hiding this comment.
Approved. Matches issue #2603 scope exactly — three named sites fixed correctly with the canonical wasVisible-guard pattern from #2580. Filing a follow-up for four additional sites the original catalog missed (ConnectionPanel, AetherialAudioStrip, FloatingContainerWindow frameless and always-on-top).
…2646) (#2685) PRs #2580 and #2635 (closing #2603) applied the `if (wasVisible) setGeometry(geom)` guard across most `setFramelessMode(bool)` implementations. Four sites with the same code-shape were missed by both passes — fix listed in #2646: 1. ConnectionPanel::setFramelessMode 2. AetherialAudioStrip::setFramelessMode 3. FloatingContainerWindow::setFramelessMode 4. FloatingContainerWindow::setAlwaysOnTop All four captured `wasVisible` and `geom` early but called `setGeometry(geom)` unconditionally after `setWindowFlags(flags)`. On a cold-launched (never-shown) instance, `geom` is the default top-left rect and the unconditional `setGeometry` clobbers Qt's normal placement, leaving the window stuck at (0,0) on first show. Closes #2646. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Fixes #2603
What was changed
fix(gui): wasVisible-guard setGeometry in three more frameless toggles (#2603)
Files modified
src/gui/PanFloatingWindow.cppsrc/gui/PropDashboardDialog.cppsrc/gui/RadioSetupDialog.cppGenerated by AetherClaude (automated agent for AetherSDR)