64a756175083ec506b997080cff32fc04549538f
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 KeelrLeek
|
75a95405a8 |
the acrylic rides move drags: only a real resize parks the glass at blur
Kyle: "when clicking and dragging the window the window gets light." It did, by design that no longer had a reason: WM_ENTERSIZEMOVE parked the accent at plain BLURBEHIND for EVERY modal loop, move drags included, on the old assumption that a suspended acrylic punches through on moves the same way it does on resizes. Plain blur ignores the gradient tint and has none of the acrylic's material dimming — measured over a striped backdrop, every glass surface stepped ~15% brighter (band luma 45.5 -> 52.2) for the whole of every titlebar drag. And no compensation was possible: move loops emit no resize-drag event, the frontend never hears about them. Measured on this machine (research/glass-drag harness, SC_MOVE posted so no synthetic mouse goes near the UI, GUI_INMOVESIZE as ground truth): DWM composites the acrylic straight through a move loop. Re-asserted mid-loop it restored rest luma EXACTLY (45.5/31.8/29.4), stationary and through 28 frames of real mouse-speed motion — no punch-through, no trailing. So the swap is now gated on SIZING_LATCH: a titlebar move keeps the acrylic, a latched resize parks at Blur exactly as before (DWM genuinely suspends acrylic in live resizes — that half is load-bearing and stays). The WM_SIZING belt-and-braces arm swaps the accent too, so a resize the hit-test latch misses still degrades one mouse-move late instead of never. Verified after: entering a move loop changes nothing to the decimal; entering a resize loop still swaps (+6.7 band luma, the intended trade) and restores on release. |
||
|
KeelrLeek
|
385b598170 |
glass survives the window gestures: the accent rides the modal loop and the maximize animation gets a bracket
Kyle reported the blur "being masked by just going opeque" on maximize, and separately the desktop punching through a maximized window. Both were the same transition, and the old guard covered neither honestly. THE GUARD'S SIGNAL IS NOW THE MODAL LOOP ITSELF. thumbbar.rs already subclasses the main window for the taskbar transport, so the size loop is three arms on that existing proc: WM_NCLBUTTONDOWN carrying a sizing hit-test (or SC_SIZE, the keyboard path) latches "this loop is a RESIZE", WM_ENTERSIZEMOVE arms, WM_EXITSIZEMOVE releases, and WM_SIZING arms as a second net because this window is undecorated and tao does its own NCHITTEST. Emitted as soulseek:resize-drag, POSTED to ourselves rather than emitted inline: emitting from inside DefWindowProc's modal loop reenters the wry runtime's window store while that loop holds it. The signal and the failure are then the same object, which is what the two previous attempts were not. The first grounded on any DOM `resize` — one event fires for a maximize, so the settled window sat flat black for ~70ms hiding glass that was already back. The second discriminated on event CADENCE, and that is the one worth remembering: on this 4-core laptop, re-rasterising every backdrop-filter at each new size pushes `resize` deliveries far apart, and measured 2026-08-28 events 150ms apart never grounded AT ALL — a real drag stayed see-through, shipping the exact artifact the guard exists to prevent. Cadence is not a proxy for the loop. DWM SUSPENDS THE ACRYLIC INSIDE THE LOOP but keeps compositing the plain BLURBEHIND, so the accent swaps down to Blur for the gesture and back on release (window_glass refactored into apply_accent + an Accent enum; GLASS_ON tracks the main window so the subclass can re-assert). The window stays glassy through a drag instead of going black — which is what Kyle actually wanted, and GROUND_DRAG is off on his verification by hand. THE MAXIMIZE ANIMATION SCALES A SNAPSHOT the accent cannot ride: measured at 43ms/frame, desktop icons read sharply THROUGH the maximized window until ~613ms after the call. Disabling the DWM zoom animation removed the punch-through outright and every frame of a ground-suppressed maximize showed the blur soft and present — but that also removed the animation, and Kyle chose the animation back with the canvas grounded across the recomposition. So transitions are forced ON, the subclass brackets the jump (active at WM_SIZE, a re-assert immediately and again at 650ms, release with the second), and GROUND_DISCRETE paints the canvas for exactly that bracket. Both policies are one-line JS constants in glass.js — flipping between "animation + dark bracket" and "instant snap + live glass" needs no rebuild. The DOM resize listener survives as the fallback for a build with no subclass, reverting to the original behaviour; it stands down for good the moment one native event is heard. Measured clean: 3 maximize/restore gestures, 3 brackets, canvas never opaque outside them; a 9-second modal loop held with zero resize events in it. 98/98 tests. |
||
|
KeelrLeek
|
f0c2bb5ed3 |
taskbar: transport buttons under the window preview
Hovering the taskbar button pops a preview, and an app may put buttons under it. Every media player uses them for the transport, and now so do we: previous, play/pause, next, with the middle one swapping its glyph as playback starts and stops. Clicks are emitted as `soulseek:media-button` — the same event the OS media card sends — so the frontend's existing dispatch handles them with no new code and the two surfaces cannot drift apart. Verified by posting the exact WM_COMMAND/THBN_CLICKED the shell posts: next advanced the queue, toggle paused, toggle resumed. Three Win32 facts shaped the implementation. The buttons can only be added ONCE per window and only after the shell has created the taskbar button, which it announces with a registered message — but Tauri shows the window before the setup hook runs, so that announcement is usually already gone by the time we could subclass, and the first build put no buttons up at all. They are added directly at init now, with the first playback as a retry for the case where the taskbar button genuinely does not exist yet. Clicks arrive as WM_COMMAND, so hearing them means subclassing Tauri's window — SetWindowSubclass chains rather than replacing the window procedure, so wry still receives everything it expects. And ITaskbarList3 is apartment-threaded, so it lives in a thread-local touched only on the UI thread, with updates from the player's event thread marshalled through run_on_main_thread. The glyphs are drawn at runtime rather than shipped: they are four flat shapes, and a .ico per glyph per theme would be files to keep in step with a transport that already draws itself in the app. Coverage is sampled on a 4x4 grid per pixel, which is what stops a 16px triangle looking like a staircase. They follow SystemUsesLightTheme — the thumbnail flyout rides the system theme, not the app's — and are rebuilt on WM_SETTINGCHANGE when that flips, so they do not end up dark-on-dark. |