In gcal_calendar_monitor_init(), self->shared.lock is initialized with
g_rw_lock_init(). On Linux/glibc, GRWLock allocates memory for the
underlying pthread_rwlock_t (56 bytes).
Because g_rw_lock_clear() was never called in gcal_calendar_monitor_finalize(),
every finalized GcalCalendarMonitor leaked its lock resources, failing the
LeakSanitizer CI build when test_calendar_monitor_expand_recurrences was added.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
When searching for events, users are typically interested in finding the
event rather than seeing a repetitive list of every occurrence instance.
By configuring the search timelines with "expand-recurrences" set to FALSE,
recurring events are loaded as their single master component instead of
expanding all individual occurrences.
Additionally:
- Update GcalSearchHitEvent subtitle to display "Recurring" (e.g. "Tomorrow • Recurring"
or "Recurring") when the event has a recurrence rule.
- Safeguard gcal_event_format_date() when running without a default GApplication.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/991
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
Add an "expand-recurrences" boolean property (defaulting to TRUE) to both
GcalCalendarMonitor and GcalTimeline. When set to FALSE:
- Recurring master components are kept as single events without expanding
each recurrence instance.
- Detached recurrence instances are ignored.
- Pruning outside range retains recurring master events so they are not
prematurely removed.
- Subscriber filtering permits recurring master events within the
subscriber model.
This allows consumers like search providers to avoid expanding all recurrence
instances when searching, improving performance and avoiding duplicate hits.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>
John Cardullo