-
v0.3.22 Stable
eugene released this
2026-06-19 20:40:07 -07:00 | 2 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 | 5 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 | 7 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 | 9 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 | 11 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 | 13 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
-
v0.3.16 Stable
2026-06-11 15:58:49 -07:00 | 16 commits to main since this releasegotifyBoard v0.3.16
What's fixed
Dark-theme toast countdown bar (for real this time)
v0.3.15's Phase 58 fix removed the rail/bar blending in the dark theme, but
the bar was still invisible while its CSS transition was running — only
visible when you hovered the toast and the timer paused. Light theme was
unaffected.Root cause: the bar was animating via
transform: scaleX(N)with a CSS
transition. Undercolor-scheme: dark, the WebView's GPU-composited
transform layer wasn't repainting the bar during the animation. Frozen
states (no transition) rendered fine, which is why pausing on hover showed
the bar correctly.Fix: switch the bar's animated property from
transform: scaleXto
width. This drops the bar onto the normal layout/paint path — the same
path used by the (always-working) undo-delete countdown bar — and the
WebView paints it every frame on both themes.The rAF-armed two-step and the pause-on-hover behaviour are unchanged. The
existingprefers-reduced-motion: reduceoverride still suppresses the
transition.Files changed
src/components/notifications/ToastCard.tsx— countdown bar JSX (one
block).
Downloads
-
v0.3.15 Stable
2026-06-11 08:08:02 -07:00 | 19 commits to main since this releaseUpdater artifacts for v0.3.15 — see https://gitea.euronvault.com/eugene/gotifyboard/releases/tag/v0.3.15 for full release notes.
Downloads
-
gotifyBoard v0.3.14 Stable
2026-06-08 02:13:57 -07:00 | 21 commits to main since this releaseUpdater binaries for gotifyBoard v0.3.14
Downloads
-
v0.3.13 Stable
2026-06-05 16:49:35 -07:00 | 25 commits to main since this releaseTooling majors (Tailwind 4, ESLint 10, Vite 8), tray unread badge, quit button.
Downloads