fix(notifications): do not show battery notification when already charging

[marcinjahn]

Description

I had a case where:

1. Laptop wasn't charging, it was working on battery
2. Battery fell to 20%
3. I got the notification about battery being low, asking me to charge (good)
4. I connected a charger
5. After short time I got the same notification again (bad)

This should fix it.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Refactor / internal cleanup
• Documentation
• Other

Related issues

Screenshots / video

Checklist

• My code follows the conventions in CONTRIBUTING.md
• I have tested my changes locally
• New user-facing strings are wrapped in I18n.tr() with translator context, reusing existing terms where possible
• Go changes: ran make fmt, added/updated tests, make test passes, and go mod tidy is clean
• QML changes: ran make lint-qml with no new warnings
• I have opened a corresponding pull request in dlx-docs to document any new behaviors: https://github.com/AvengeMedia/DankLinux-Docs

[purian23]

The race diagnosis makes sense, though this introduces a five-second grace window around the AC transition. We generally prefer reacting to the underlying power/UPower state changes rather than relying on timing where possible. Is the grace period needed because there isn’t a reliable follow-up event we can key off here, or could this be resolved when the relevant battery/charging state update arrives instead?

I've personally not ran into this one before. Once I plug in AC charging the status is satisfied.

[bbedward]

/claude review

[claude]

Clearing these flags on plug-in re-arms the alert and can reintroduce the duplicate this PR is fixing (and in a case that worked before).

Trace: alert fires at 20% (_hasNotifiedLowBattery = true) → user plugs in → these lines reset the flag and _lastPluggedInTime starts the 5s window → if the device takes longer than 5s to report Charging (the comment at L134 says it can be "a few seconds", and UPower refresh intervals can be ~30s), the next batteryLevelChanged sees isCharging === false and _recentlyPluggedIn() === false and sends "Low Battery" again. Without this reset the stale true flag would have suppressed it regardless of the grace window.

The reset isn't needed for the normal path either: onIsChargingChanged (L226-228) already clears both flags once charging actually starts. Dropping these two lines keeps the grace period as a pure suppression and makes the fix strictly safer.

[claude]

Claude review

One issue: the new flag reset on plug-in can re-trigger the very duplicate this PR targets.

• Resetting _hasNotifiedLowBattery/_hasNotifiedCriticalBattery in onIsPluggedInChanged re-arms the alert, so a Charging report arriving later than the 5s grace window fires "Low Battery" again — a case that was previously suppressed by the stale flag. onIsChargingChanged already clears both flags when charging actually starts. quickshell/Services/BatteryService.qml:254

Checked: the full diff against BatteryService.qml notification/plug-in/charging state paths, I18n usage (no new strings), and existing review comments (the timing-vs-event-driven concern raised by @purian23 still stands and is not repeated here). Model: claude-opus-5.

[marcinjahn]

The race diagnosis makes sense, though this introduces a five-second grace window around the AC transition. We generally prefer reacting to the underlying power/UPower state changes rather than relying on timing where possible. Is the grace period needed because there isn’t a reliable follow-up event we can key off here, or could this be resolved when the relevant battery/charging state update arrives instead?

I've personally not ran into this one before. Once I plug in AC charging the status is satisfied.

It happened to me just once, I think it might be difficult to reproduce consistently. I tried solving it the way I did, because I didn’t know of a better way.
And yes, it is hacky, up to you whether it’s worth merging in.