noframe: drop the drag-by-surface -- it is a finishing step, not a mode

Author's correction to the shape of yesterday's option.  The intended workflow
is: place the displays where you want them WITH their frames, quit, then edit
glass_layout.cfg to turn the frame off.  So a ,noframe window should be pinned,
not draggable -- removed the WM_NCHITTEST -> HTCAPTION handler that made the
surface a drag handle.

The arrangement being finished is the point: with no caption there is nothing
to drag it by, which is exactly what you want on a wall of monitors.  Delete
the flag to get the frame (and the dragging) back.

Unchanged and still needed: SaveLayout writes the flag back, because any later
drag of a FRAMED window rewrites the whole file and would otherwise strip it.

Re-verified live:
 - Heat MFD comes up with WS_CAPTION clear and answers WM_NCHITTEST on its
   surface with HTCLIENT (pinned) -- no window reports HTCAPTION any more.
 - Comm MFD (unflagged) keeps its caption.
 - A framed window's WM_EXITSIZEMOVE rewrote the file and BOTH ,noframe flags
   survived, with the new header explaining the arrange-first workflow.
 - surround / exploded / pod / dev boot and simulate clean.

Docs updated to describe the two-stage workflow rather than surface dragging:
the file's own header, environ.ini's BT_GLASS_LAYOUT block, context/
glass-cockpit.md and the ledger (which records the removed behaviour so the
next reader does not re-add it).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-29 11:26:11 -05:00
co-authored by Claude Opus 5
parent f5f4c6c198
commit aa788bc56d
4 changed files with 57 additions and 55 deletions
+16 -14
View File
@@ -141,27 +141,29 @@ analogue of TeslaRel410 `emulator/pod-launch`'s per-rig `--bridge-pos`/`--layout
### `,noframe` — per-window chrome removal (2026-07-29) [T2 live]
Append it to a window's line and that window loses its title bar and border (`WS_POPUP`) — for a
multi-monitor wall where the chrome is just noise:
Append it to a window's line and that window comes up with no title bar or border (`WS_POPUP`) —
for a multi-monitor wall where the chrome is just noise:
```
Heat MFD=1920,0,657,539,noframe
```
Hand-edited (the file is otherwise machine-written). Options are comma-separated after the
numbers and **unknown ones are ignored**, so an older build reading a newer file loses the option
but never the line — the `bindings.txt` grammar rule applied here.
**The workflow is deliberately two-stage, and this is the last step:** run with
`BT_GLASS_LAYOUT=save` and drag the windows where you want them (they have title bars, so it is
the normal sticky-layout flow) → quit → hand-edit the cfg and append `,noframe` to the ones you
want bare. From then on those windows are frameless **and pinned** — with no caption there is
nothing to drag them by, which is the point: the arrangement is finished. Delete the flag to get
the frame back.
Two consequences it has to carry, or the option would be a trap:
- **A frameless window has no title bar to drag** — which is the entire sticky-layout workflow.
So a `noframe` window is dragged **by its surface**: `WM_NCHITTEST` returns `HTCAPTION`
anywhere that is not a button and `HTCLIENT` over one, so buttons stay clickable and the drag
still ends in `WM_EXITSIZEMOVE` and still saves.
- **`SaveLayout` rewrites the whole file**, so it writes the flag back — otherwise the first save
after a drag would silently strip it.
Options are comma-separated after the numbers and **unknown ones are ignored**, so an older build
reading a newer file loses the option but never the line — the `bindings.txt` grammar rule
applied here.
The flag is read BEFORE frame sizing (a `LoadLayout(quiet)` pre-pass), because `AdjustWindowRect`
and therefore `ComputeLayout`'s ring placement depend on whether a window carries chrome.
The one thing it must not do is eat itself: **`SaveLayout` rewrites the WHOLE file** (any later
drag of a framed window triggers it), so it writes the flag back for every window carrying it.
And the flag is read BEFORE frame sizing (a `LoadLayout(quiet)` pre-pass), because
`AdjustWindowRect` — and therefore `ComputeLayout`'s ring placement — depends on whether a window
carries chrome.
Verified live: two flagged windows came up caption-less while the other five kept theirs, a click
still dispatched on the frameless radar (`CLICK 'Secondary / Radar' addr=0x18`), and a