Thanks for this @jensenpat — nice, focused fix. The approach (preserving native overlapped-window style bits and hiding the frame via WM_NCCALCSIZE instead of leaning on Qt::FramelessWindowHint) is the standard Windows custom-frame contract and is the right way to get Snap Assist back. AppSettings usage matches our conventions, scope is appropriate (4 files, all Windows-frame related), and the non-Windows behavior is untouched.

A few observations / questions — none blocking, just want to make sure they're intentional:

1. setFramelessWindow(bool on) ignores on on Windows — src/gui/MainWindow.cpp:12895

The Windows branch always calls applyWindowsCustomFrame() regardless of on. Tracing it through:

• The on parameter only controls what gets persisted to AppSettings("FramelessWindow") at the top of the function.
• applyWindowsCustomFrame() triggers SWP_FRAMECHANGED, which fires WM_NCCALCSIZE, and nativeEvent then re-reads the (just-saved) setting via mainWindowCustomFrameEnabled() to decide whether to swallow the message.

So toggling on=false on Windows does end up restoring native chrome via the redraw path, which is correct — but it's pretty non-obvious. A one-line comment in the Windows branch explaining that applyWindowsCustomFrame() works for both directions because nativeEvent gates on the persisted setting would save the next reader a lot of head-scratching.

2. m_sizeGrip visibility when on=true on Windows — src/gui/MainWindow.cpp:12916

With the new Windows path, edge/corner hits from WM_NCHITTEST already give native resize, so the bottom-right QSizeGrip is redundant (and may double up visually with the snap-aware resize edges). Worth confirming this isn't visually awkward, or hiding the size grip unconditionally on Windows when custom-frame is active.

3. applyWindowsCustomFrame() ORs style bits but never removes WS_POPUP — src/gui/MainWindow.cpp (the new function)

desiredStyle = style | WS_CAPTION | WS_THICKFRAME | .... If style happens to still have WS_POPUP set (e.g. from a stale flag state), this preserves it alongside WS_CAPTION, which Win32 treats as conflicting. With the constructor change to skip Qt::FramelessWindowHint on Windows this shouldn't happen in practice, but explicitly masking off WS_POPUP (desiredStyle = (style & ~WS_POPUP) | WS_OVERLAPPEDWINDOW) would make it robust against future changes that might re-introduce the flag.

4. QCursor::pos() vs the WM_NCHITTEST lParam — src/gui/MainWindow.cpp (in nativeEvent)

You correctly use nativePos (from GET_X_LPARAM/GET_Y_LPARAM) for the resize-edge math because it's in physical pixels, then switch to QCursor::pos() for the isSystemMoveAreaAt check because that helper operates in Qt logical coordinates. Just confirming this is intentional — fine in practice, but worth a one-line comment so a future reader doesn't "fix" the inconsistency.

Otherwise looks good. The TitleBar::isSystemMoveAreaAt helper is a clean separation, and routing the title-bar drag through WM_NCLBUTTONDOWN / HTCAPTION (instead of startSystemMove) is the right call given the Qt 6.8.3 hit-test skip.

_{🤖 aethersdr-agent · cost: $4.7125 · model: claude-opus-4-7}