KeelrLeek
f0c2bb5ed3
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.