6 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	edff6eedc9	fix(player): let the background-audio toggle govern backgrounding again ... Locking the screen kept a video's audio playing whether or not the background-audio button was on. Reported as "audio only mode is always active even if not selected". The button (UR-040) was built for the WebView <video> path, where losing visibility kills the decode: it chose between handing off to a native audio stream and letting playback stop. Native video then became the default renderer (DR-188), and on that path playback runs through ExoPlayer inside a MediaSessionService -- a foreground media service whose entire purpose is to keep playing while the app is hidden. Nothing stopped it, and nothing in the codebase paused on background. So the button governed a handoff that no longer had a gap to bridge. There was no interruption to paper over, and a user who never touched it got background playback anyway. The gating made it self-concealing: MainActivity.onStop only dispatched 'jellytau-background' when backgroundAudioEnabled was already true. The one notification that the app had gone away was itself conditional on the setting, so with the button OFF nothing could react even in principle. onStop and onStart now fire unconditionally and carry the two facts only the activity knows -- whether the toggle is armed, and whether Android put the window into picture-in-picture. What to do about it is decided in Rust (player/background_policy.rs), because it depends on whether the item has a picture to lose: video + toggle off -> Pause video + toggle on -> HandOffToAudio music, either -> KeepPlaying (no picture to give up) picture-in-picture -> KeepPlaying (the window is still on screen) It takes no renderer parameter on purpose. Two renderers with two behaviours and one toggle reaching only one of them is what produced the defect; a rule that cannot see the renderer cannot reproduce it. Two failure modes are deliberate. A decision call that fails leaves playback alone rather than risking silence mid-listen. An event with no detail -- older Kotlin against newer JS -- reads as "armed, not PiP", degrading to the previous behaviour instead of pausing unexpectedly. Foregrounding resumes only what backgrounding paused: a video the user paused themselves before locking stays paused. Written test-first per CLAUDE.md. The stub encoded today's behaviour (nothing ever pauses) and failed exactly as reported -- `left: KeepPlaying, right: Pause` -- before the rule was implemented. Verified on a device, R8-minified, both directions: [player_background_action] video=true armed=false pip=false -> Pause [player_background_action] video=true armed=true pip=false -> HandOffToAudio UR-040 / DR-224 / UT-211.	2026-08-22 10:09:46 +02:00
dtourolle	30a9cb32f5	chore(release): v0.10.0 ... Two user-visible features -- the app can update itself, and it can hand you a redacted diagnostics bundle -- plus the supply-chain, release integrity and build work behind them. A minor bump rather than a patch, matching how v0.9.0 was cut off v0.8.2 for a single new user requirement. This one carries two (UR-077, UR-078), both with UI in Settings. The CHANGELOG entry is the release body now: build-release.yml publishes the `## v0.10.0` section and fails if it is missing, instead of the fixed block of install instructions that every release from v0.0.1 to v0.9.1 carried verbatim.	2026-08-21 22:32:04 +02:00
dtourolle	16658889a2	fix(home): restart the hero banner timer on a manual change ... The rotation interval was installed once when the banner mounted and never touched again, so a swipe, arrow or dot tap inherited whatever was left of the running countdown — swiping 5.5s into a 6s interval moved the banner on half a second later. The timer moves into heroRotation.ts as a small restartable object so it can be unit-tested, and every manual navigation path restarts it from that moment. Verified red-first: with restart() reverted to leave a running timer alone, the regression test fails. Release 0.9.1.	2026-08-20 23:11:30 +02:00
dtourolle	98b2ede8bd	fix(arch): build with custom-protocol so the package can load its own UI ... The PKGBUILD ran a bare `cargo build --release`. Without `--features tauri/custom-protocol` Tauri does not embed the frontend and serves it from devUrl instead, so the package compiled, linked, installed and passed every check — then launched into "Could not connect to localhost: Connection refused". `tauri build` passes that feature for you and the Android build passes it explicitly; this path never did, so the Arch package has never worked. Adds a check() that catches it at build time. It tests for the *assets*, not for the dev URL: devUrl is part of the config blob generate_context!() embeds either way, so grepping for it reports a failure on a correct build. A content-hashed filename from the vite output can only appear if the bundle was embedded — which is also why the fixed binary is ~400 KB larger. Found by installing the package and launching it, which is the only thing that would have found it.	2026-08-20 22:43:34 +02:00
dtourolle	4f4741cee5	fix(release): stamp the Arch package version, and ship the licence with it ... pkgver sat at 0.0.18 while the tree was on 0.8.x, because the Arch package is built by makepkg rather than the tauri bundler and set-version.sh never touched it. makepkg produced a package whose version bore no relation to the source it was built from — the exact failure that script exists to prevent, in the one file it had missed. Dev versions are converted to a pkgver Arch accepts: a hyphen separates pkgver from pkgrel, so 0.9.0-3-gabc1234 becomes 0.9.0.r3.gabc1234. pkgrel resets to 1, since a new upstream version restarts its packaging revisions. Also installs LICENSE into /usr/share/licenses — MIT is not in Arch's common licences, so a package under it has to carry the text. Arch is not part of the automated release (build-release.yml covers linux, windows and android), so v0.9.0 is unaffected; this applies to anyone building the package by hand.	2026-08-20 22:26:35 +02:00
dtourolle	742ad88a29	feat(build): cross-platform desktop packaging; bump to 0.1.0 ... Adds Docker-based packaging for Linux desktop (deb/rpm), Arch (.pkg.tar.zst via makepkg), and Windows. Windows cross-compiles from Linux via the official Tauri path — the x86_64-pc-windows-msvc target driven by cargo-xwin — and produces an NSIS installer (nsis via tauri.conf.json targets, since the CLI rejects --bundles nsis on a Linux host). Verified end to end: builds jellytau.exe + jellytau_x64-setup.exe. Unifies everything on one registry builder image (Dockerfile.builder): Android SDK/NDK, rpm/file, clang(+clang-cl)/lld/llvm/nsis, cargo-xwin and the msvc target. Packaging tools sit in a trailing layer so tool changes rebuild in ~1min instead of ~15. Desktop stages are thin FROM ${BUILDER_IMAGE} layers; Arch uses a separate archlinux image. CLAUDE.md: CI must install no system toolchains — everything lives in the image. Bumps version 0.0.18 -> 0.1.0 (Windows support + webview audio + equalizer). TRACES: UR-003, UR-005 | DR-004	2026-07-24 23:49:50 +02:00