Fixes a few problems in the schedule comparison code:
- Same recurrence pointer short-circuits to TRUE: a pointer to the
same recurrence is not a sufficient condition, because the dates
could still be different (this is especially true if the recurrence
is NULL for both events, but also holds if that is not the case).
Also deleted the explicit check if only one of the recurrence
pointers is NULL, because that is the first thing that is checked
in `gcal_recurrence_is_equal()` anyway.
- Date comparisons only check if the date moved into a specific
direction: the correct logic is to check if they are not the same,
no matter in which direction the date moved.
- The time is not compared: for non all-day events, it is necessary
to compare the time values too. The glib function that is now used
for that also checks the date, so these checks can be collapsed
into one.
For the second and third point it seems like some things got a bit
mixed up in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/2ee6dfc5e7bd5823bee5029a7ac3a32d3c247ba9:
- The `gcal_schedule_section_changed()` implementation already used the
`g_date_time_equal()` function (which is now used again).
- It was `gcal_schedule_section_day_changed()` which only compared the
dates using `gcal_date_time_compare_date()`, but this function was
only used for edits to recurring events to determine whether to
allow changing all instances. This commit now exposes a regression
in this part of the code, which is tracked separately in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1612>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/792>
This adds:
- `gcal_event_alarms_equal()`
- `gcal_event_schedule_equal()`
- `gcal_event_strings_equal()`
We aren't going to make use of it yet, but eventually these functions
will be used for the event editor dialog, as well as writing tests for.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
Using GDateTime utilities is costly and shows up high in profiling.
That's because GDateTime has to run timezone offset checks for every
comparison. We can amortize this cost by converting these datetimes
to unix timestamps upfront, and using them for comparisons.
A complication is date-only ranges, for which unix timestamps wouldn't
work. For this, add a new kind of timestamp that only accounts for the
dates.
Add a new test case for date-only comparison.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/770>
The previous sorter was a simple GcalRange proxy, but we need a more
robust and stable sorting mechanism. Use multiday, start and end dates,
length, and finally the last modified date to sort events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/761>
GSequence is useful and provides us with a convenient API, however,
it pretty much guarantees cache misses when iterating, lots of pointer
chasing, and scattered memory.
gdkarrayimpl.c works around all of that, at the cost of more expensive
additions and removals. But because we do a lot more lookups compared
to edits, there should still be benefits to it.
Change the backing store to be based on gdkarrayimpl.c.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/757>
Augmented timelines increase the range of dates from its subscribers
by the specified factor. They're useful for the interactive views,
since they prevent fetching new events so often as when views change.
Add the necessary API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/755>
Add a GtkFlattenListModel that flattens out all events from the
calendar monitors. Keep a GtkFilterListModel, and a GtkSortListModel,
for each subscriber. Manually update the filter when the range of
the subscriber changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
This is a GListModel implementation that is specific to
GcalEvents. Events are stored in a GSequence in order of
date.
Add a couple of tests exercising additions and removals.
WIP: add more tests
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
Add on_collection_source_refreshed() callback. Track collection
source refresh in clients_synchronizing. Refresh collection sources
before calendar clients. Fix PROP_SYNCHRONIZING state by waiting for
all async ops.
Add a wrapper for the ECalComponentOrganizer. An instance of this type
is kept as part of the GcalEvent structure.
The GcalEventOrganizer is just a "proxy" to the ECalComponentAttendee
and its purpose is to unclutter the GcalEvent interface and provide a
bindable base for a UI widget.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/671>
