[fix] Frameless toggle not propagating to open floating windows#2059
[fix] Frameless toggle not propagating to open floating windows#2059chibondking wants to merge 1 commit into
Conversation
Switching View → Frameless Window updated the main window chrome but left any already-open floating panadapter or applet windows unchanged, because setFramelessWindow() in MainWindow only modified its own Qt::FramelessWindowHint flag. PanFloatingWindow and FloatingContainerWindow had the flag hardcoded at construction and were never updated at runtime. Changes: - PanFloatingWindow constructor now reads AppSettings["FramelessWindow"] instead of hardcoding Qt::FramelessWindowHint, so newly created windows open in the correct mode. - PanFloatingWindow::setFramelessMode(bool) added — setWindowFlags + setGeometry + show() to switch a live window without losing position. - FloatingContainerWindow constructor same fix. - FloatingContainerWindow::setFramelessMode(bool) added. - PanadapterStack::setFramelessMode(bool) — iterates all live floating panadapter windows and calls setFramelessMode on each. - ContainerManager::setFramelessMode(bool) — same for applet windows. - MainWindow::setFramelessWindow() now calls both after updating itself. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Clean, well-scoped fix. The approach is correct — reading the setting at construction and propagating at runtime via a dedicated setFramelessMode() method on each window type.
A few observations:
Looks good:
- Uses
AppSettings::instance()(not QSettings) — matches project conventions. setFramelessMode()correctly saves/restores geometry and visibility, same pattern asMainWindow::setFramelessWindow().- Null-checks on
m_panStackandm_appletPanel->containerManager()in MainWindow. - The
ContainerManager::setFramelessModeloop has aif (win)guard — defensive but reasonable for a map that could have stale entries during teardown.
One minor concern — race with PR #2058 (FramelessResizer):
If #2058 lands first, toggling frameless mode at runtime will recreate the native QWindow (that's what setWindowFlags does). The FramelessResizer event filter is installed on the QWindow — after setWindowFlags() + show(), the old QWindow is destroyed and a new one is created. The resizer would need to re-install itself (it mentions handling QEvent::WinIdChange for exactly this scenario, but only from the constructor path). Worth confirming that WinIdChange fires on the widget even when setWindowFlags recreates the native window mid-session, not just on first show. If those two PRs are intended to merge together, a quick manual test of: toggle frameless while a floating window is open → verify resize edges still work, would be sufficient.
No blocking issues. This is a straightforward propagation fix that stays well within scope. Thanks @chibondking!
…2067) Originally by @chibondking — propagates View → Frameless Window setting to all popped-out panadapters and applet containers, instead of leaving them with hardcoded Qt::FramelessWindowHint. - PanFloatingWindow / FloatingContainerWindow constructors now read AppSettings["FramelessWindow"] instead of hardcoding the flag. - New setFramelessMode(bool) on both window classes flips the flag at runtime, preserving geometry + visibility. - PanadapterStack::setFramelessMode and ContainerManager::setFramelessMode iterate live floating windows and propagate the toggle. - MainWindow::setFramelessWindow calls into both managers. Resolved one trivial conflict in PanadapterStack.h where the new setFramelessMode declaration overlapped with the saveFloatingState/ restoreFloatingState block from #2065. Closes #2059. Co-authored-by: CJ Johnson <cj@cedrick.io> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Claude here on Jeremy's behalf — auto-closed via the merge trailer in #2067. Cherry-picked the four-file diff onto current main and tested all four toggle paths (frameless ON ↔ OFF with floating windows open, and fresh launches with each setting). All worked as designed. One trivial conflict to resolve in Both changes credited to you in the merged commit (0cfb051). Thanks again for the careful split-out from #2008. Last one (#2058 — FramelessResizer) is up next. 73, Jeremy KK7GWY & Claude (AI dev partner) |
…windows (#2068) Originally by @chibondking — popped-out panadapter and applet windows use Qt::FramelessWindowHint which removes OS-provided resize borders. Previously a single QSizeGrip in the bottom-right corner; unreliable on Wayland and only one corner. FramelessResizer is a small QObject event filter installed on the QWindow (native handle) — sees mouse events at the platform level before they're dispatched to the widget hierarchy. Edge proximity within 6 px → cursor change + startSystemResize on left-click. Crucially, never touches the widget event stream, so nested controls (knobs, drag tiles, chain widget) respond normally even when near the window edge. Resolves the regression that caused the v1 implementation (#2008) to be reverted. Two cursor-leak guards added on top of the cherry-pick: - Destructor calls leaveEdgeZone() so windows destroyed while at an edge don't leak the override cursor onto the desktop. - The existing leaveEdgeZone() inside the eventFilter Phase 2 early return (when the window flips to decorated mode at runtime via #2059's setFramelessMode) ensures the override is restored when the resizer becomes a no-op. Closes #2058. Co-authored-by: CJ Johnson <cj@cedrick.io> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Switching View → Frameless Window updated the main window chrome but left any already-open floating panadapter or applet windows unchanged, because setFramelessWindow() in MainWindow only modified its own Qt::FramelessWindowHint flag. PanFloatingWindow and FloatingContainerWindow had the flag hardcoded at construction and were never updated at runtime.
Changes: