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>
Now that GcalTimeline properly notifies about the complete state,
it uncovered an issue where GcalShellSearchProvider was dereferencing
a NULL pointer.
Protect against that.
Now that we keep precise control over GcalEvent instances, and
can use simple pointer comparisons everywhere, GcalMonthView
implemented its update function as a simple remove + add pair.
The problem is that we're not passing the old event instance,
so removals never actually happen, since the new instance is
not yet available to subscribers.
Pass old event in additio to the new one, and use it where it
makes sense.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1073
Right now, comparing dates with gcal_date_time_compare_date() gives
the exact opposite result of when comparing using g_date_time_compare().
As shown by this patch, this was a source of *many* bugs.
Most of these are probably paranoid, not bugs. I haven't done an
exhaustive review to see what really needs it: that would be
time-consuming and require significant familiarity with the Calendar
codebase. This was just a quick check. Anyway, I vote for paranoid
when it comes to using g_signal_connect() regardless. It's dangerous,
and there's no reason to ever leave a signal connected after the user
data object has been destroyed.
Fixes#423
John Cardullo