refactor(gui): remove dead startSystemMove branch in ContainerWidget (#2601)#2645
Conversation
…ethersdr#2601) PR aethersdr#2576 centralized frameless title-bar move handling in FramelessMoveHelper but left ContainerWidget::onTitleBarDragStart() with a stray startSystemMove() call that: 1. Has no Q_OS_MAC guard — would re-introduce the macOS 5–10s dead-zone bug if the branch ever fired 2. Has no return-value check or fallback Tracing the state machine, the branch is currently unreachable: ContainerTitleBar::mousePressEvent early-returns when m_isFloating is true and never sets m_pressed, so mouseMoveEvent never emits dragStartRequested — onTitleBarDragStart is only reached in the docked state where m_dockMode == DockMode::Floating is false. Removing the dead branch per the issue author's recommendation (option a). If floating-mode container drag ever returns, the correct integration point is FramelessMoveHelper, not the raw QWindow::startSystemMove primitive. Also drops the now-unused <QWindow> include. Co-authored-by: Don @ cloaked.agency <don@cloaked.agency> & K6OZY
There was a problem hiding this comment.
Verified the state-machine analysis against src/gui/containers/ContainerTitleBar.cpp:
mousePressEvent(line 159) hands off toFramelessMoveHelper::startand returns without settingm_pressedwhenm_isFloating == true.mouseMoveEvent(line 175) early-returns when!m_pressed, sodragStartRequestedis never emitted in floating mode.- Therefore
ContainerWidget::onTitleBarDragStartis unreachable while floating, and the removed branch was the last rawstartSystemMove()caller after #2576.
Also confirmed <QWindow> is unused elsewhere in the file once the branch is gone, so the include removal is correct.
Tight scope (13 lines, one file), no behavior change, and the PR description correctly points future floating-drag work at FramelessMoveHelper rather than reintroducing the bare primitive. Thanks @Ozy311 for the careful trace and the cleanup.
ten9876
left a comment
There was a problem hiding this comment.
Approved. State-machine trace verified — the deleted branch was genuinely unreachable. Deletion is the right call over guarding: leaves no unguarded raw primitive to resurface the macOS 5-10s dead-zone bug class if the two floating-state flags ever desync; if floating-mode container drag returns, it should route through FramelessMoveHelper like everything else after #2576.
Summary
Removes the unreachable
startSystemMove()branch fromContainerWidget::onTitleBarDragStart()per option (a) in #2601, plus the now-unused<QWindow>include.Why
FramelessMoveHelper; this was the one stray raw-primitive caller left behind.Q_OS_MACguard and no fallback ifstartSystemMove()refuses — both of which would reproduce the macOS 5–10s dead-zone bug class that Fix intermittent frameless title-bar drag on macOS #2576 just fixed.ContainerTitleBar::mousePressEventearly-returns whenm_isFloating == trueand never setsm_pressed, sodragStartRequestedis never emitted in floating mode). Easier to delete than guard.Scope
src/gui/containers/ContainerWidget.cpponlyContainerWidget.hand call sites are untouched — only the inner dead branch and its dead<QWindow>include go awayIf floating-mode container drag returns
The correct integration point is
FramelessMoveHelper, consistent with every other title bar after #2576 — not the bareQWindow::startSystemMoveprimitive this PR removes.Test plan
ninja -C buildclean on Linux (Nobara 43, Qt 6.10.3, gcc 15.2.1) — rebuildsAetherSDR+ the threecontainer_*_testtargets without errorsCloses #2601
73, Ozy K6OZY
AI compute partnership: cloaked.agency — drafted with Don, our VP of Engineering agent, on Linux dev stack (
nobara-dell).