When the until's time part is invalid, the libical claims the time
as valid, but the conversion into the GDateTime fails and returns NULL.
Such events, which claim to have until-date recurrence, but NULL 'until'
cannot be edited, because they cause a crash of the application.
More information can be found downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=2135772
Related to https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/892
When we receive the 'objects-modified' signal, we get components
that may represent main events. We also may receive components
that have no recurrency because they were just changed from being
recurrent to non-recurrent.
We need to handle all these cases properly.
If the event has no recurrency set, remove any potential old
recurrence instance lingering around. If we're changing an event
with recurrency, make sure the recurrency instances are in sync
with the new recurrency.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/881
(or so I hope.)
We'll start accessing the hash table from multiple threads, so
it must be in the shared section of the structure, and it must
be encapsulated by locking.
While fixing timezone bugs, it was found that the calendar property needs
to be set before the component property. The component times may require
to have the calendar set, to be able to lookup the custom timezones in the
calendar, thus make sure the calendar is set before the component is set,
during the construction time.
Rework the initialization process so that setting the construct-only
component property merely takes a hold on the references; and the actual
setting up of the event happens during g_initable_init().
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/788
If we can't find an appropriate timezone, query the ECalClient
for it and give it an extra chance of finding the right timezone.
Thanks to Milan Crha for proposing this fix.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/444
All-day events always use UTC, so when the multiday detection code was
converting them to the local timezone, they span an additional day if
the local timezone is not the same as UTC. This was leading to all-day
events always being considered multiday events.
Fix this by ignoring the timezone for all-day events, like all other
comparisons do. Also don't consider all-day events spanning 1 day to be
multiday since as per RFC 5545 the end date is non-inclusive and if
omitted to be start + 1 day.
Zero length ranges, such as for events without a DTEND could be
considered to overlap a range if they were at exactly the end of the
range. The end of a range however is the first date that is supposed to
not overlap, so a zero-length range on exactly this point should not be
considered overlapping.
This fixes cases where all-day events from the next month could show up
on the same day of the current month if they did not have a DTEND.
This also adds tests for all possible cases of such zero-length events
overlapping.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/701
On systems without anything providing the org.freedesktop.timedate1
interface, the timezone returned by the monitor would always be NULL,
because it was never set. This can lead to crashes in places that expect
the monitor to always return a valid timezone. So in that case use the
local timezone from when the monitor got initialized.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/703
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
Cloning an ECalComponent can fail, and we need to be able to
catch these failures.
Assert that cloning was successful before procceeding with
the move.
The behavior of gcal_range_compare(), and the 'position' argument
of gcal_range_calculate_overlap(), should be the same. However,
because we were comparing the end dates in the wrong order, they
didn't match.
Fix that by properly comparing the end of the ranges.
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.
