Redesign the titlebar right-click menu: real separators/headers, live customization

Reported live: "looks very ugly currently and some of it doesn't make
sense." Both were real. Every row, including a bare divider, took one
full TITLEBAR_HEIGHT slot, so a separator was a 1px hairline in the
middle of 32px of empty space; "Move to Workspace" faked a section
caption by embedding box-drawing characters directly in an ordinary
item's label, which rendered - and behaved, until the click-dispatch
site's own special case - exactly like a clickable row that did
nothing. Separately, "Floating" was always offered even though
Window::floating only affects the "tiling" layout: toggling it under
this project's own default "dynamic" layout visibly changes nothing,
reading as a broken control rather than an inapplicable one.

ContextMenu (crates/core/src/context_menu.rs) gained real Separator
(9px) and Header (22px, non-interactive, dimmed) row kinds with their
own small heights, replacing the label-hack outright. Both backends'
rendering now sum each row's own real height instead of assuming one
uniform value, so hit-testing and pixels can't disagree about where a
row is. Floating is omitted entirely outside the tiling layout.

New, in direct response to "allow customizing from there as well": a
Customize section with live Button Style / Button Side toggles. Each
flips the matching ThemeConfig field and immediately redraws every open
window's titlebar - not routed through srd set's own path, which is
scoped to windows created after the call for lack of a redraw hook it
can reach; a menu action that didn't visibly change the titlebar you
clicked would be its own "doesn't make sense" bug.

Full workspace build/test/clippy clean (242 core tests, +8; 152
wayland, net-even after rewriting the old label-hack tests).

1 files changed, 16 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index 2cace23..691e63b 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,5 +1,21 @@
 # TODO / planned features - master checklist
 
+## Titlebar right-click menu redesigned: real separators/headers, an inapplicable item hidden, live customization added (2026-08-28)
+
+Reported live: "looks very ugly currently and some of it doesn't make sense." Both were real, found by reading `srdwm_core::context_menu` and `decoration::render_context_menu` directly rather than guessing at what "ugly" meant.
+
+**Ugly, root-caused:** every row - a real item or a bare divider - occupied one full `TITLEBAR_HEIGHT` (32px) slot, so a separator was a 1px hairline sitting in the middle of 32px of mostly empty space, and the "Move to Workspace" section divider faked a caption by embedding literal box-drawing characters directly in an item's own label (`"─── Move to Workspace ───"`) - which rendered, and behaved (right up until the click-dispatch site's own special-cased check), exactly like a normal clickable row that happened to do nothing.
+
+**Doesn't make sense, root-caused:** "Floating" was always offered, but `Window::floating` is only ever read by `arrange_workspace`, which only runs anything for the `"tiling"` layout - toggling it under this project's own default `"dynamic"` layout (and the user's own stated preference for dynamic/floating day to day) visibly changes nothing at all, which reads as a broken control rather than an inapplicable one.
+
+Fixed all three properly rather than patched around: `ContextMenu` (`crates/core/src/context_menu.rs`) gained two new row kinds, `Separator` (now genuinely small, `SEPARATOR_HEIGHT` = 9px) and a real `Header` (`HEADER_HEIGHT` = 22px, non-interactive, dimmed text, never highlighted) that replaces the old label-hack entirely - both backends' rendering (`decoration::render_context_menu`'s new `MenuRowKind`, and X11's own `redraw_context_menu`) now sum each row's own real height (`ContextMenu::row_height_for`/`row_y`) instead of assuming one uniform height, so a hit-test and a pixel can never disagree about where a row actually is. "Floating" is now omitted entirely when the window's own workspace isn't running the `"tiling"` layout.
+
+**New, in direct response to "allow customizing from there as well":** a "Customize" section with two live toggle rows - Button Style (traffic-lights / traditional) and Button Side (left / right), the exact two knobs already named in an earlier live request this session. Clicking either flips the matching `ThemeConfig` field and immediately redraws every open window's titlebar (`redraw_every_decoration` on Wayland, `redraw_all_decorations` on X11) - deliberately *not* routed through the same path `srd set button_style`/`button_side` use, since that path (`crates/platform`, backend-agnostic) is scoped to "only affects windows created after this call" for lack of any redraw hook it can reach; a menu action that didn't visibly change the very titlebar you clicked would be exactly the "doesn't make sense" complaint this whole redesign was about. Decoration mode (server/client) was considered and deliberately left out of this section: it's negotiated once at map time, so changing it can never affect an already-open window either, and there's no clean way to make it make sense here the way the redraw trick does for button style/side.
+
+Both backends stay in exact sync on the underlying data (`srdwm_core::context_menu` is genuinely shared, not two drifting copies) - X11's own rendering keeps its existing "feature parity, not pixel parity" stance (no per-pixel colour blending for a dimmed header the way the Wayland renderer's `mix_rgb` gives it; the header row is still correctly sized and non-interactive, just not visually dimmed there).
+
+Verified via the rendering function's own pixel-level unit tests (rounded panel, correct per-row heights, hairline separator, dimmed non-highlighted header text) plus the full `ContextMenu` row-construction test suite (Floating hidden/shown by layout, customize labels reflecting live theme state, no gaps/overlaps across variable row heights). Full workspace build/test/clippy clean (242 core tests, +8 for this menu's own new behaviour; 152 wayland, net-even after rewriting the old label-hack tests into real `MenuRowKind` ones). **Not independently screenshotted interactively** - opening the real menu needs a physical right-click, and synthetic input (`ydotool`) operates at the uinput level, not scoped to any one nested test instance, so it isn't safe to fire blind the way this file's own standing caution about it already establishes; the pixel-level tests are what stand in for that here.
+
 ## Root cause found and fixed: tiled windows tinted dark along a shared edge (2026-08-28)
 
 Reported live as "some windows are dark tinted" (via a peer session, `dotfiles-1a`, who diagnosed the actual cause and handed over a concrete fix rather than a symptom). Root cause verified by reading the rasteriser before touching anything: `shadow_bitmap` never tints a window's own interior, and no rule sets `opacity` on the affected windows - the tint was never a content property. It was a shadow-versus-gap-size mismatch. `SHADOW_SIZE` is 24px; `gap_inner` on this session's live config is 1px. `redraw_decoration_buffer`'s shadow gate (`crates/wayland/src/state/lifecycle.rs`) only excluded a maximized or fullscreen window, so every *tiled* window got the same 24px shadow too - with only 1px of real gap for it to fall into, it landed almost entirely on the neighbouring tile instead, darkening it by up to `SHADOW_MAX_ALPHA` (~35%). The focused window is raised above its neighbours, so this showed up as the *unfocused* side of a shared tile edge reading tinted.