Feat/calendar reminders

[yevhen-sychov]

What's missing today

Calendar accounts sync and events are displayed, but nothing ever tells you an event is about to start. The reminder data is discarded before it can be used:

• ical_parser.h documents that VALARM is ignored, so a reminder set in a calendar app never reaches the shell
• CalendarEvent has no field to carry one
• the Google client never reads reminders / defaultReminders
• nothing compares an event against the current time

CalendarService already holds a NotificationManager*, but only for OAuth and keyring failures.

What this adds

Reminder notifications for upcoming events, honouring the reminder you actually set in your calendar app, with a configurable fallback for events that carry none.

• VALARM triggers from CalDAV/ICS feeds — DISPLAY/AUDIO actions, relative and absolute triggers, RELATED=END
• Google reminders — overrides, and useDefault resolved against the calendar's own defaults
• All-day events get a single once-a-day digest rather than a burst at midnight
• Missed reminders fire once on startup if the event has not begun yet, so a reminder due while the shell was down is not lost
• Reminders stay until dismissed and persist in history — one that fades while you are away from the desk is the case this feature exists to prevent
• Events with a resolved meeting link are clickable, opening the link

New config, all under [calendar.reminders]:

[calendar.reminders]
enabled              = true
use_event_reminders  = true     # honor per-event reminders; off = always use the default lead
default_lead_minutes = 10       # for events with no reminder of their own; 0 = at event start
all_day_digest_time  = "09:00"  # "" disables the digest

Please look closely at this part

One change is outside the calendar module and deserves review: src/notification/ gains two narrow opt-ins rather than a blanket change to internal-notification behaviour.

• NotificationRequest::persistInHistory — internal notifications are toast-only today, which is right for every current caller (battery warnings re-fire, credential failures resurface in settings, the migration reminder re-arms). A calendar reminder is the first whose entire value is a moment in time with no other surface. Filters still apply and Urgency::Low stays excluded.
• Actions on notifications of internal origin are dispatched in-process instead of to the D-Bus callback. An internally generated notification has no D-Bus owner, so ActionInvoked was being emitted into the void; this also makes internal notifications able to respond to a click at all.

Happy to split this into its own PR if you'd prefer it reviewed separately.

Design decisions worth knowing

Lead offsets, not absolute instants. Recurrence expansion builds each occurrence by copying the base event and overwriting only start/end, so relative leads are inherited by every instance with no change to addRecurrence. It also matches Google's native model and keeps the cache small.

A pure planner plus a thin monitor. planReminders() is a free function over a snapshot, the config, the fired set and a caller-supplied "now" — no NotificationManager, ConfigService or D-Bus — which is what makes the firing rules testable. CalendarReminderMonitor is the stateful shell, modelled on BatteryWarningMonitor.

One firing rule covers in-session firing, startup catch-up and dropping stale reminders: due, not already fired, and still relevant — meaning the event has not started, or the reminder came due within a five minute grace. That grace is what makes an at-start reminder (TRIGGER:PT0S) possible at all; it comes due exactly at the start, so requiring a future event would make it unsatisfiable.

Its own poll source. CalendarService::pollTimeoutMs() only advertises a deadline while a refresh is pending, and refresh_minutes reaches 240, which would leave reminders up to four hours late. When nothing is armed the new source reports no timeout, so an idle shell gains no wakeups. Deadlines are kept in wall-clock time, since a monotonic poll() timeout does not advance across suspend.

Bounded state. Fired reminders are keyed by (uid, start, lead) and pruned once past the grace window, which bounds the set without a horizon watermark — a watermark would silently swallow a reminder for a freshly accepted invitation whose lead has already elapsed. Reminders are capped per event, per catch-up pass, and at rest.

Some deliberate omissions, all documented in the code: a VALARM's REPEAT/DURATION snooze ladder is ignored, absolute triggers on recurring events are skipped (they fire once for a series, not per occurrence), and snooze/actions beyond opening the link are out of scope.

Testing

Three new test binaries and extensions to two existing ones: VALARM trigger forms including the TRIGGER:PT0S and RELATED=END edge cases, Google reminder resolution, the firing rules under an injected clock, and the notification opt-ins. just test is green, and each of the 7 commits builds on its own, so the history bisects.

Verified live against a real account, which turned up two bugs now fixed and covered by regression tests: at-start reminders could never fire, and a meeting carrying two reminders notified twice on a cold start.

Not covered by automated tests: the toast rendering and the browser actually opening, both of which need a running compositor.

🤖 Generated with Claude Code