Improve minimal mode window controls#2290
Conversation
There was a problem hiding this comment.
Thanks for this @jensenpat — the title-bar drag dead-zones and the "maximize → full-screen minimal strip" trap have both been minor papercuts. Diff scope is tight (4 files, all on-topic) and the approach is sound.
A few notes, mostly minor:
Stuck m_windowMoveActive after a successful startSystemMove — when the compositor takes over the move, the release usually doesn't come back to us, so m_windowMoveActive stays true. continueWindowMove() self-heals on the next button-less MouseMove (your !(ev->buttons() & Qt::LeftButton) check calls finishWindowMove), so this is benign in practice. Worth a one-line comment near startWindowMove saying so, since it looks like a leak on first read.
handleTitleDoubleClick and the isAccepted() check (TitleBar.cpp:413 area) — QMouseEvent::isAccepted() defaults to true, so when handleTitleDoubleClick early-returns on a non-left button, mouseDoubleClickEvent still sees ev->isAccepted() == true and skips QWidget::mouseDoubleClickEvent. Same in the menu-bar / drag-handle filter branches that return me->isAccepted(). Not a regression vs. the prior code, but if you want the early-return to fall through to the base class, add ev->ignore() before the early return in handleTitleDoubleClick.
Double showNormal() in exitMinimalModeToWindowedMode — this works (the first un-maximizes, the second un-does any state toggleMinimalMode may have implied), but it's non-obvious. A short comment would save the next reader a git blame.
m_skipMinimalModeGeometrySave reset — fine as written, but worth noting it's only safe because toggleMinimalMode(false) runs synchronously. If anyone later defers the geometry save (singleShot, queued), the flag will already be false by the time the save runs. Not asking for a change, just flagging the invariant.
Conventions check: AppSettings::instance() used correctly, parent-owned widgets, QSignalBlocker around the action-checked toggle — all consistent with the rest of the file. No new boundary I/O so no error-handling gaps.
Leaving as a comment only — not requesting changes. LGTM once you decide on the comments above.
ten9876
left a comment
There was a problem hiding this comment.
LGTM — verified the maximize-in-minimal-mode bug on main and traced the fix path. Drag-gutter approach is right; small follow-up nits left in review comment but none blocking. Thanks @jensenpat!
Summary
Why
In minimal mode, users expect the maximize button to restore the full windowed UI rather than create a full-screen minimal strip. The custom frameless title bar also had invisible dead zones because spacer items are not widgets, and compositor-managed startSystemMove can be unreliable when invoked from child hit areas on macOS.
Validation
👨🏼💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat