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>
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>
Timeline subscribers (i.e week_view, month_view, agenda_view, date_chooser) were not
properly notified of event(s) moved out of their listening ranges.
We notify them to remove these events.
fixes: #994 and #1043
This patch do not sends ADD_EVENT for events that are multiday and are
part of the old_range when calling calculate_changed_events. This will
prevent multiday duplicate events to appear in the agenda widget when
using the week view.
If the event is a multiday and it was in the previous range, it won't
send the REMOVE_EVENT so multiday events won't dissapear when it's still
relevant.
See https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/898#note_1602391
When removing the last subscriber (something that can happen when
closing the main window), GcalTimeline clears the event queue. But
that leaves us in an inconsistent state, as we don't process any of
the potentially removed events.
Don't do that.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1087
Don't try and track the number of completed calendars; instead,
recalculate the completed state from scratch every time. This
is not a performance concern, as we're dealing with at most some
hundreds of calendars.
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
This should save quite some resources when manipulating events.
Signals are relatively expensive, and 2 pointer chases are
definitely better than a global lock + FFI stashing + signal
manipulation.
In on_calendar_monitor_completed_cb() we have this assert:
g_assert (self->completed_calendars <= g_hash_table_size (self->calendars));
That is comparing a signed integer to unsigned. This is dangerous. We
could add casts to say that we really want to do it, but
completed_calendars should never be negative, so might as well use
unsigned.
Since 78cb11c64d, GcalCalendarMonitor now
notifies when a completed calendar transitions to incomplete, and
GcalTimeline decrements its completed_calendars counter. But we forgot
to remove the code that resets completed_calendars when previously
needed. That's not required anymore, because we can trust
GcalCalendarMonitor to do the right thing.
In my case, I have 5 calendars enabled and 6 total. When starting
gnome-calendar, all 5 are successively completed, and
completed_calendars increments from 0 -> 1 -> 2 -> 3 -> 4 -> 5. Then,
when transitioning month view from January 2020 to December 2019, we
call reset_completed_calendars() and completed_calenders gets clobbered
to 0. Then it decrements from 0 -> -1 -> -2 -> -3 -> -4 -> -5 as the
GcalCalendarMonitors notify that they are no longer completed. Well,
that is what would happen, if it didn't crash when decrementing to -1.
We assert -1 <= 6 (the total number of calendars) and crash because -1
gets promoted to a huge unsigned int, since we're comparing signed to
unsigned. (That crash would have been avoided if we used
-Wsign-compare, although that warning would not have caught the logic
problem.)
Anyway, since GcalMonitor now notifies when calendars are no longer
complete, it is safe to simply remove reset_completed_calendars().
GcalTimeline will still notify if it needs to change its own complete
property (in on_calendar_monitor_completed_cb).
Fixes#567Fixes#636Fixes#638Fixes#647Fixes#650
Moving to have one subscriber per event made us face an interesting
problem: when removing an event, there may be no subscribers that
contain this event, in which case we never queue any REMOVE_EVENT
and the range tree isn't updated.
Add sentinel events (that update the range tree) and subscriber events
(that update subscribers, but not the range tree).
When we add an event to the queue, and later remove it, if the
event is still in the queue, we can just cancel both out and
save the timeline some processing time.
When the old and the new range of the subscribers don't
overlap entirely, we can't use the regular diff algorithm.
It fails quite spectacularly.
Do a full cleanup when ranges don't overlap.
g_source_destroy doesn't free memory, just removes the source from its
main context. We have to do both. (g_source_unref() might call
g_source_destroy() if it has the last ref, but if something else has
another ref, then disaster could result if we don't call it manually.)
A batch size of 5 doesn't seem to impact the mainloop
any more than a batch of size 1, but it reduces the
amount of time spinning the loop quite considerably.
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.
