The return value is nullable, but gnome-calendar fails to check it.
Because the nullable return value is inconvenient for us, we can instead
add and use gcal_context_get_icaltimezone() to supplement the existing
gcal_context_get_timezone().
We'll also need a function to convert from GTimeZone to ICalTimezone,
gcal_timezone_to_icaltimezone().
Fixes#419
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
This was originally discovered and fixed by Milan Crha; I'm just
forward-porting his fix to the master branch. self->clients takes
ownership of this source but we don't currently have ownership here,
leading to a double free vulnerability.
Fixes#435
While deleting the calendar, we may run into a situation
where the GcalCalendar instance is destroyed before the
GcalManager:calendar-removed signal is emitted, causing
us to emit the signal with a destroyed object.
Prevent that by increasing the ref count before emiting
the signal.
Instead of other classes needing to manually set and
unset whether a source is registered in the data model,
we can now simply call GcalCalendar.set_visible() and
have the model be updated for us.
