4 Commits

Author	SHA1	Message	Date
Matthew Harris Glover	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
ChrisBeWithYou	cc75cb876a	fix(library): tuning filter answers for your instrument, not always guitar (#1003) ... * fix(library): tuning filter answers for your instrument, not always guitar The library indexed exactly one tuning per song, chosen guitar-first (lead > rhythm > combo, bass only as a last resort), and nothing consulted the player's instrument. A bassist filtering by tuning was shown the guitar chart's tuning, so playlists built by tuning contained songs needing a retune. Reported by a tester building bass practice sets; Covet "Shibuya" is the clean case, with a custom guitar tuning over a standard bass chart. Indexes each arrangement role's own tuning and makes the facet, filter, sort and labels answer for one perspective. `guitar-lead` reads the original unprefixed columns and adds no payload keys, so the default response is unchanged. The same defect existed inside guitar -- lead and rhythm charts can disagree -- so perspective is three-valued (guitar-lead, guitar-rhythm, bass) driven by one PERSPECTIVES table rather than parallel column families. Songs with no chart for the perspective fall back to the song-level tuning rather than vanishing (18 of 59 packs in the test library have no bass chart), but the fallback is marked inferred in the facet counts and on the row instead of being silently coalesced. "Only real charts" reuses the existing `arrangements_has` filter rather than adding one. Bass-specific handling, from measured content: - Bass tuning arrays are padded to six entries; charts never reference string index 4 or 5. Truncated to four before naming and grouping. - Grouping uses a canonical open-pitch key, so [-2,0,0,0] and [-2,0,0,0,0,0] are one facet row instead of two. - Offsets above +1 semitone are refused a name. Bassists tune down, near never up; one pack ships [5,5,5,5,4,4] (A-D-G-C, unplayable, and its own notes sit in the song's real key under standard tuning). Naming that would send a player to retune to a tuning that does not exist. Rhythm deliberately does not truncate -- padding is a bass finding, and cutting a seven-string array would invent a tuning the chart lacks. Adds an opt-in `tuning_match=playable` mode alongside exact match: a chart is offered when your lowest open pitch is at or below its lowest open pitch, so a five-string bass covers four-string standard and drop-D with no retune. Open strings only -- note range is not indexed and the scan stays manifest-only -- so it fails conservative: unknown low pitch is excluded, and the upper bound is unchecked and documented rather than guessed. Existing installs would otherwise never populate: the tree-signature fast path reports "unchanged" forever on a settled library. Rows with NULL marker columns re-extract, and the fast path is disabled until that backfill converges (writes use '' rather than NULL, so it self-clears). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SFDokqh2H6mEjk1Kgbi6JW Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> * test(v3): accept the tuning-perspective indirection in the badge guard The album-art badge now reads shownTuningName(), so the source-pattern guard no longer matched the inline `tuning_name || tuning` form and CI went red. Accept the helper, and pin the helper's own fallback in a companion test so the guard still fails if a guitar player's tuning label is ever dropped. Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> --------- Signed-off-by: ChrisBeWithYou <christian.a.cowan@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 00:04:30 -05:00
gionnibgud	f8012a8ce4	feat(v3): add desktop-only "Start in fullscreen" system option ... Adds a "Start in fullscreen" toggle to the Settings → System panel, addressing the desktop request in feedBack-desktop#97: users want the app to launch fullscreen without hitting the OS hotkey every time. The block ships hidden and is gated exactly like the App-updates block: setupWindowOptions() only unhides + wires it when the feedBack-desktop bridge exposes window.feedBackDesktop.window.{getStartFullscreen, setStartFullscreen}. Web/Docker builds have no such bridge, so the section never appears there. Persistence lives desktop-side because only the Electron main process can read the pref at window-creation time — core just proxies through the bridge. The desktop bridge + launch behaviour land in a follow-up feedBack-desktop PR. Signed-off-by: gionnibgud <gionnibgud@gmail.com>	2026-07-13 12:38:24 +02:00
Byron Gamatos	84fe29688c	refactor(app): carve settings into static/js/settings.js (R3d) (#920) ... 22 declarations, 446 lines. app.js 4,218 -> 3,772. Bodies VERBATIM. Settings load/save, the AV-offset nudge, the default-arrangement pin, the instrument pathway, and the app-update channel. ━━━ INTERFACE WIDTH 1, AND IT GOT THERE BY DRAWING THE BOUNDARY IN THE RIGHT PLACE ━━━ app.js calls loadSettings() and nothing else. The first cut was NOT clean: _defaultArrangement was written from OUTSIDE the cluster, and an imported binding is READ-ONLY, so that one write would have forced a setter or a state container — as it did for the player (player-state.js) and the library (library-state.js). But the writers were saveSettings and pinCurrentArrangementDefault, which ARE settings functions. Widening the slice to include them left ZERO outside writes. Every export is now a plain read-only import and no container is needed. Worth naming, because I reached for a container twice before: the fix for "this binding is written from outside" is sometimes a container, and sometimes it just means the boundary is in the wrong place. Measure the writers before you build machinery. ━━━ handleSliderInput STAYS A HOST HOOK, DELIBERATELY ━━━ It lives in settings now (it is a settings control), but player-controls.js must NOT import it: this module already imports player-controls (_applyMastery, _autoplayExitEnabled, …), so a direct back-import would close a cycle. player-controls keeps reading it through the host seam, and app.js — the root, which imports both — wires it. That is exactly what the seam is for, and the contract test proves the wiring survived. VERIFIED. A/B against origin/main in two browsers: the window contract, the settings screen rendering, the AV-offset and default-arrangement controls present, and a real `input` event dispatched on a slider — which is the path that goes through the host seam. IDENTICAL, zero page errors. node 1045, pytest 2425, ESLint 0 (no-cycle clean), host contract 2/2, Codex 0. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 14:08:45 +02:00