2 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
4 people	270cb39f41	Enable Linux nightly AppImage auto-update in the System settings UI (#999) ... * fix(settings): enable Linux nightly AppImage auto-update in System settings Fixes the Settings → System "App updates" panel so it actually works on Linux, and adds Nightly as a selectable channel — previously missing entirely, so Linux self-update couldn't be reached from this UI at all. - The channel dropdown no longer gets permanently disabled the moment the desktop bridge reports 'unsupported', which is the normal state whenever the channel isn't Nightly on Linux. It stays enabled so the user can switch to Nightly, the only way out of that state. - Shows live download progress ("Downloading update… N%") and an explicit button state machine (Check → grayed out while busy → Restart now once staged), instead of a frozen "Checking…" during the ~1.5GB background download. - Renders every status update from the triggering action's own return value (checkNow()/setChannel()'s result) rather than a separate follow-up getStatus() call, which can race against other state changes and show a stale result even after a real success. - setupAppUpdates() no longer re-syncs the channel to the backend on every Settings-panel re-render — only once per page load — so a redundant sync can no longer stomp an in-flight download's state. - Routes update-flow events into the existing diagnostics.js console-capture + contribute() snapshot API, so the user's existing "Export Diagnostics" button now captures the full update decision trace end to end — no new UI or log file. This diagnostic tracing is what actually root-caused the bugs above, from real on-device captures rather than guesswork. Companion PR in feedBack-desktop (the underlying update engine). Verified end-to-end on a Steam Deck: channel switch → check → live download progress → restart button → relaunch onto the new build, confirmed via a real Export Diagnostics capture showing a clean, fully-accounted-for trace. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(settings): extract + unit-test the app-update status view; dedupe diag log - Extract the status→UI state machine from renderFrom into a pure, exported _appUpdateStatusView() (DOM-free) and cover it with tests/js — settings.js's large module graph made importing it for a full harness impractical, so the pure function is the testable seam. Behavior-preserving; renderFrom applies the returned shape to the DOM exactly as before. - Dedupe the [update-diag] renderFrom console line so the ~1.5s download poll no longer floods the diagnostics ring buffer with byte-identical entries; every real state/percent change still logs, and the structured contribute() snapshot stays unconditional. Left the 'audio_engine' diagnostics key as-is: the server export filters client contributions to loaded plugin ids (diagnostics_bundle.py path-traversal guard), so a dedicated key would be silently dropped from the bundle. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Byron Gamatos <xasiklas@gmail.com> --------- Signed-off-by: Byron Gamatos <xasiklas@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Byron Gamatos <xasiklas@gmail.com>	2026-07-19 12:16:02 +02:00
4 people	23c509322b	Add gamepad/controller support (#1001) ... * feat(input): add gamepad/controller support Adds full gamepad/controller navigation and playback control, driven by requests from players who use fee[dB]ack on a TV/console setup and from wheelchair users for whom a controller is far more convenient than a keyboard + mouse. Confirmed working end-to-end on a Steam Deck across several rounds of on-device testing. - static/v3/gamepad.js: polls navigator.getGamepads() and dispatches synthetic keydown events (Arrow/Enter/Space/Escape) on the focused element (falling back to document), reusing the app's existing keyboard pipeline (static/js/shortcuts.js's scope-aware dispatcher, player shortcuts, text-field/modal guards) instead of a parallel action-mapping table. Only acts on gamepads reporting the W3C "standard" mapping — which is what Steam Input presents for the Deck's built-in controls, both in Gaming Mode and in Desktop Mode via a non-Steam shortcut — so button order is guaranteed correct and a non-standard/raw device safely no-ops instead of misfiring. Handles Steam Input's virtual-pad duplicates (a real controller plus 1-2 mirrored XInput slots) without spamming connect toasts or losing input when the live pad isn't at index 0. Xbox-style face button mapping: bottom face = Space (play/pause, and activates the focused control), right face = Escape (back), top face reveals the player screen's tool rail (focuses it into visibility via the existing CSS :focus-within rule). D-pad/stick repeat while held, mirroring OS keyboard auto-repeat. - static/v3/gamepad-nav.js: fills the one real gap in that reuse strategy — no screen but the song library grid had any arrow-key navigation, and Chromium doesn't run native Enter/Space button activation for untrusted synthetic events even when dispatched at the focused element. Gated entirely on `!e.isTrusted`, so it only ever reacts to gamepad-originated events and never touches real keyboard/mouse users: emulates Tab-order (the sidebar + active screen's real, already-focusable buttons/links) for Arrow keys, explicitly .click()s the focused element for Enter/Space, and gives Escape a consistent "go back" behavior — an existing in-screen back button if one's visible (reusing each screen's own drill-down logic for free), else the main menu. Every branch defers via `e.defaultPrevented` to any screen that already handles the key itself (the song grid, the player, settings), so nothing here overrides existing behavior. - static/v3/songs.js: adds real 2D d-pad/arrow-key navigation to the song library's virtualized grid (only a slice of the library is ever in the DOM), including fetching/scrolling off-screen rows into view and correcting for the sticky filter toolbar's occlusion. - static/v3/index.html: wires up the two new scripts. * chore: regenerate stale tailwind.min.css Rebuilt in a fresh clone (not the local working copy). Several plugin directories (audio_engine, plugin_manager, community_charts, etc.) are gitignored locally but present on disk from checking out plugin repos for local dev/testing — Tailwind's content scan picks them up regardless, so a rebuild against the contaminated local working copy bakes in extra utility classes that don't belong in the real, git-tracked build. A clean checkout reproduces CI's expected output exactly. * fix(gamepad): check all matching back buttons, not just the first document.querySelector on the combined [data-ap-back], [data-albums-back], #v3-pl-back selector only ever inspects the first match in DOM order — since screens stay in the DOM (hidden, not removed) when you navigate away, a hidden back button from an unrelated screen could sort before the one that's actually visible, incorrectly falling through to showScreen('v3-home') instead of clicking it. Uses querySelectorAll + find(visible) instead. * fix(gamepad): address CodeRabbit findings on connect/disconnect and grid nav - gamepad.js: anyLiveConnectedPad -> anyLiveStandardPad, filtering by mapping === 'standard' like firstLiveStandardPad already does, and applied at the top of the gamepadconnected handler too. A still- connected non-standard raw mirror could otherwise mask the real pad's disconnect (toast never fires, polling never stops). - songs.js _gpMove: an unset cursor now always seeds at index 0 before the first press, instead of applying that press's delta immediately (ArrowDown/Right previously skipped straight past row 0; Left/Up only looked right by accident of clamping). Matches the existing convention in shortcuts.js's legacy _handleLibArrowNav. - songs.js _gpBlockedTarget: form-control/button blocking now requires the element to be visible (offsetParent !== null), not just present. Screens stay in the DOM hidden (not removed) when you navigate away, so a real button focused on some other now-hidden screen could leave document.activeElement pointing at it and block all grid navigation indefinitely. (An el.closest('#v3-songs') scope was tried first and reverted — it fixed that case but broke blocking for the topbar search input, which lives outside #v3-songs's DOM subtree even while v3-songs is active; visibility is the distinction that actually matters, not DOM nesting.) Skipped two CodeRabbit suggestions, verified against current code: gating songs.js's grid keydown listener to synthetic-only events would regress the real keyboard accessibility this PR intentionally added (v3-songs' grid had none before); renaming the _gp* helpers to drop their underscore prefix would break from this codebase's own established module-private naming convention. Verified in-browser: first arrow press lands on index 0, stale hidden focus no longer blocks grid nav, the topbar search input still correctly blocks it, and normal nav resumes after blur. * test(gamepad): unit-cover the controller + nav state machines - gamepad.test.js (10): standard-mapping filter, Steam Input duplicate-slot dedup, disconnect masking, button edge-detection, d-pad/stick repeat timing, analog deadzone — driven via a fake navigator + manual rAF queue. - gamepad_nav.test.js (10): !isTrusted/defaultPrevented gating, arrow focus traversal + clamping, hidden-element skipping, Enter/Space click activation (not into text fields/body), Escape visible-back-button vs home fallback. songs.js grid nav is left to on-device coverage (async + windowed-DOM heavy). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Byron Gamatos <xasiklas@gmail.com> --------- Signed-off-by: Byron Gamatos <xasiklas@gmail.com> Co-authored-by: Byron Gamatos <xasiklas@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 11:52:51 +02:00