-
gotifyBoard v0.3.26 Stable
eugene released this
2026-09-25 16:46:26 -07:00 | 2 commits to main since this releasegotifyBoard v0.3.26
Released: 2026-09-25
This patch release makes in-app updates restart the app on Linux and adds a way to
dismiss a burst of popups in one click.Fix: "Install and restart" on Linux
On Linux, Settings → About → Install and restart installed the new package (after
the password prompt) but never relaunched the app. The Updates panel stayed on
"Downloading and installing…" and the old version kept running until it was closed
by hand. Windows was unaffected because its installer closes and relaunches the app
itself.The app now restarts itself once the install finishes, showing "Update installed.
Restarting gotifyBoard…" first. The restart goes through a normal app exit so the
single-instance lock is released before the new copy starts.One-time note: the restart runs in the version being updated from. Updating to
v0.3.26 from an older version still needs one manual close and reopen. Updates after
v0.3.26 restart automatically.New: Clear all popups
When an app sends several messages at once (for example Lidarr importing an album),
the popup stack now shows a Clear all (N) button once two or more popups are
visible or waiting. One click dismisses every visible popup, including critical ones,
and drops any that were still waiting, so nothing else slides in afterwards.Verification
- TypeScript typecheck and ESLint pass.
- 26 frontend test files pass with 241 tests.
- Rust Clippy with warnings denied passes.
- Debian, RPM, and AppImage bundles build and are signed with the Tauri updater key.
Files and data
- No database migration, Gotify server change, configuration migration, or new
dependency is required.
Rollback
Tag
v0.3.25remains available as the previous release. Rolling back removes the
Clear all button and the automatic restart after Linux updates; settings and message
history are unaffected.Downloads
-
gotifyBoard v0.3.25 Stable
2026-09-25 07:19:42 -07:00 | 4 commits to main since this releaseUpdater binaries for gotifyBoard v0.3.25
Downloads
-
gotifyBoard v0.3.24 Stable
2026-09-01 09:01:27 -07:00 | 6 commits to main since this releaseUpdater binaries for gotifyBoard v0.3.24
Downloads
-
gotifyBoard v0.3.23 Stable
2026-08-31 20:00:49 -07:00 | 8 commits to main since this releaseUpdater binaries for gotifyBoard v0.3.23
Downloads
-
v0.3.22 Stable
2026-06-19 20:40:07 -07:00 | 10 commits to main since this releasePhase 66: Fix feed detail-pane scrolling regression from v0.3.21. AppShell main is now a flex column so only the left card list scrolls; the detail pane body scrolls internally with footer pinned. Bottom gap stays gone.
Downloads
-
gotifyBoard v0.3.21 Stable
2026-06-19 09:51:00 -07:00 | 13 commits to main since this releaseUpdater binaries for gotifyBoard v0.3.21
Downloads
-
v0.3.20 Stable
2026-06-17 00:42:51 -07:00 | 15 commits to main since this releasegotifyBoard v0.3.20
What's fixed
Toast window no longer lingers as a bare dark rectangle after the last card
Users intermittently reported that when a toast card finished exiting
(either auto-dismiss or user click), the toast window would remain on
screen as a featureless dark rectangle until the next notification
arrived. Most of the time it worked correctly. The pattern showed up
most often with short dismiss durations or when the user clicked X on
a card within ~200 ms of it appearing.Root cause. The visibility effect in
src/toast/ToastApp.tsxwas an async IIFE with no cancellation or
serialization guard. The show path has 4+ IPC awaits
(setSize,pickMonitor,get_monitor_work_area,setPosition,
show) — easily 10–250 ms of round-trips to the Rust backend. The
hide path is a single fastdismiss_toastinvoke. When effect A
(show, slow) was still mid-pipeline and effect B (hide, fast) ran
and completed first, effect A's finalwin.show()resolved last and
re-showed the window — by which pointToastAppwas renderingnull
because the stack was empty. The user saw the body's opaque
--gb-bgcolor (the toast window isn't OS-transparent), and the
state stuck untilstack.lengthchanged again (next notification).Fix. Every visibility effect run now chains off a shared
Promisequeue, so hide segments wait for prior show segments to
complete in order. The show segment also re-checks
latestStackLenRef.current(updated synchronously on every effect
entry) immediately before its finalwin.show()— if the desired
state has flipped to "hidden" while we were awaiting positioning IPC,
we bail before showing, and the queued hide segment that caused the
flip will run next.Files changed
src/toast/ToastApp.tsx— addedvisibilityOpsRefand
latestStackLenRef; wrapped the existing visibility effect body
inside a chained.then(async () => { ... }); added a
pre-win.show()guard that bails when the latest desired length
is 0.CHANGELOG.md— v0.3.20 entry.package.json,src-tauri/Cargo.toml,src-tauri/Cargo.lock,
src-tauri/tauri.conf.json— version bump to 0.3.20.docs/plans/phase-64-toast-window-stays-visible.md— approved
plan from Phase 64.
Verification
npm run typecheck,npm run lint,npm test— all green
(24 files, 221 tests).- Manual: with toast dismiss = 3 s on the Linux dev build, fired
notifications and either clicked X within ~200 ms or let them
auto-dismiss. The bare-dark-rectangle state did not appear. - Stacked behavior verified: 3 toasts in rapid succession, mixed
click-dismiss and auto-dismiss — window hides cleanly when the
last card exits.
Rollback
git revert v0.3.20and re-runscripts/patch-latest-json.mjswith
v0.3.19 URLs and signatures. v0.3.19 assets remain at tagv0.3.19
oneugene/gotifyboardandeuronvault/gotifyboard-updates. The
v0.3.19 toast countdown behaviour (= v0.3.15) returns; the intermittent
window-lingering bug returns with it.Downloads
-
gotifyBoard v0.3.19 Stable
2026-06-11 20:54:01 -07:00 | 17 commits to main since this releaseUpdater binaries for gotifyBoard v0.3.19
Downloads
-
v0.3.18 Stable
2026-06-11 18:50:17 -07:00 | 19 commits to main since this releasegotifyBoard v0.3.18
What's fixed
Toast countdown bar under "Show animations off" (Windows)
v0.3.17 fixed the bar's visibility but it still didn't animate on
Windows if the user had Settings → Accessibility → Visual Effects →
Animation effects turned off. Linux desktops worked fine because most
DEs don't tie that toggle toprefers-reduced-motion.Root cause: Chromium/WebView2 reports the Windows "Show animations in
Windows" preference asprefers-reduced-motion: reduce. Our
globals.csshad a blanket override that disabled animations on
.toast-countdown-barunder that media query, so the bar stayed at
100% width and never decremented.Fix: drop
.toast-countdown-barfrom the reduced-motion override. The
bar is a 4px linear width animation at the bottom of the toast —
informational, non-flashing, slow — so it's safe to keep running even
when other motion is reduced. The slide-in/slide-out toast card
animations are still suppressed under reduced-motion.Files changed
src/styles/globals.css— removed.toast-countdown-barfrom the
@media (prefers-reduced-motion: reduce)selector list; added a
comment explaining why.
Verification
npm run typecheck,npm run lint,npm test— all green.- Behavior confirmed by user: enabling Windows animations made the bar
count down in v0.3.17. v0.3.18 makes that work regardless of the
Windows preference, matching Linux behavior.
Rollback
git revertthe Phase 62 commit; v0.3.17 assets remain at tag
v0.3.17on both Gitea repos. Manifest can be repointed via
scripts/patch-latest-json.mjswith v0.3.17 URLs + signatures.Downloads
-
v0.3.17 Stable
2026-06-11 17:19:09 -07:00 | 21 commits to main since this releasegotifyBoard v0.3.17
What's fixed
Dark-theme toast countdown bar (take three)
v0.3.16 swapped the bar's animated property from
transform: scaleXto
width, on the theory that a WebView compositing layer was hiding the
transformed bar undercolor-scheme: dark. That theory was wrong — the
bar was still invisible during the timer and only appeared (frozen) on
hover.Real root cause: the rAF arming pattern
(progressArmed: false → requestAnimationFrame → true) relied on the
browser painting two distinct React frames — first the "snap to full
width, no transition" frame, then the "width 0%, transition Nms linear"
frame — to seed the transition. React 19's concurrent renderer can
collapse those two state updates into a single render, skipping the
seed frame, so the transition starts and ends atwidth: 0%(an
invisible no-op). Light theme happened to win the race occasionally;
dark theme didn't.Fix: throw out the React-controlled transition entirely and use a
straight CSS@keyframes toast-countdownanimation (the same pattern
the always-working undo-delete bar uses). Scrubbing the bar to its
current position is handled with a negativeanimation-delayequal to
the elapsed time; pause-on-hover is just
animation-play-state: paused. No React state, no rAF, no transition
seeding — the browser owns the timeline.Files changed
src/components/notifications/ToastCard.tsx— replaced the
progressArmed/useState/useEffect/rAF block + the
width-transition JSX with a CSS-animation div; removed the now-unused
useEffect/useStateimports.src/styles/globals.css— added@keyframes toast-countdown(100% →
0%). The existingprefers-reduced-motion: reduceoverride at
.toast-countdown-barstill suppresses it.
Verification
npm run typecheck,npm run lint,npm test— all green (24 files,
221 tests).- The CSS keyframe approach is the same one used by
.undo-countdown-bar(globals.css), which has been working in dark
theme since it shipped, so the fix has high prior confidence.
Rollback
If this needs to be reverted,
git revertthe Phase 61 commit and
re-deploy v0.3.16 (still on Gitea releases at tagv0.3.16). The
updater manifest's Linux entries can be repointed by re-running
scripts/patch-latest-json.mjswith the v0.3.16 URLs + signatures.Downloads