mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-08-09 08:04:45 +00:00
mandClaude
ebd9a163bc
Follow-up to e9475dd079. That commit fixed the case where the user
clicked the "Enable OS notifications" button on a fresh install
(permission NotRequested \u2192 Granted) but the master toggle stayed off.
It missed the two closely-related cases the user was still hitting on
v1.13.1:
1. Permission was already granted from a previous session or install
(e.g. an earlier v1.13.0 build, or the user allowed it via
System Settings \u2192 Notifications directly). In this state,
permissionState == Granted, so the "Enable OS notifications"
button never renders \u2014 the button label promised the whole
handshake but the code path that flipped the master switch only
ran under NotRequested.
2. On Windows/Linux `permissionState` defaults to `NotApplicable`
from the moment the app starts. The master switch is off by
default (first-launch UX choice) and nothing ever flips it, so
the auto-dispatcher stayed muted forever unless the user found
the switch manually.
Fix:
- Add `NotificationSettings.wasExplicitlyDisabled()` so the Settings
screen can distinguish "master switch is off because it defaults
off on first launch" (auto-enable is fine) from "master switch is
off because the user turned it off" (leave alone). Backed by a
new java.util.prefs key `explicitly_disabled` that flips true on
`setEnabled(false)` and gets cleared on `setEnabled(true)`.
- In `NotificationSettingsScreen`, a `LaunchedEffect(permissionState,
enabled)` observes when the OS permission is Granted OR NotApplicable
and the master switch is off. If the user has never explicitly
turned it off, it auto-flips on \u2014 matching the "Enable OS
notifications" contract for the paths the previous fix missed.
- Also render a "Turn on desktop notifications" button in the
Granted branch when the user has explicitly turned notifications
off. That's the recovery path for users who deliberately opted
out and later want to opt back in without hunting for the
master switch two rows away.
Behaviour on the fresh-install macOS path (permission NotRequested)
is unchanged \u2014 that path still runs the `requestPermission()`
flow inside the button's onClick, and the auto-enable happens via
the same LaunchedEffect once permissionState flips to Granted.
Tests (jvmTest, hermetic \u2014 UUID-scoped prefs nodes so tests never
share state or pollute real user prefs):
PreferencesNotificationSettingsExplicitDisableTest:
- fresh install defaults to not-explicitly-disabled
- turning off marks explicitly disabled
- turning on clears the explicit-disable flag
- flag persists across new instances on the same prefs node
\ud83e\udd16 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>