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.
The calendar view thread can start spinning its own mainloop
before g_thread_new() returns, and in that case we have a NULL
thread.
Check that either the GThread is what we expect it to be, OR,
the thread is NULL and there are no messages in the queue.
The notify signals of ESourceSelectable seem to come from the
ESourceRegistry thread, and this has the potential to derail
the execution of Calendar. This might be true for all signals
we connect to.
Make sure to always emit notify signals on the main thread.
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.
Apparently I never properly implemented range comparison in
remove_events_outside_range(). Do so now.
This makes the infinite scrolling month view stop flickering
events when changing weeks.
Instead of smashing the main thread's mainloop with
potentially hundreds or even thousands of idles that
add, remove, or update individual events, pass arrays
of events around.
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
