The "source-removed" signal can pass any kind of source,
including source collections that even have the calendar
extension, but are not connected.

This is an embarrassing mistake: when an error is propagated,
we always need to return! The error matching should only be
used for deciding whether to warn or not.

#470
#264

We need to disconnect from the GcalManager when the GcalQuickAddPopover
is destroyed, or crashes happen.

GObject automatically notifies when passing
properties as part of g_object_new(). This
happens after the instance is created, thus
after constructed().

By passing G_PARAM_EXPLICIT_NOTIFY, we avoid
this behavior. However, we are still notifying
PROP_CONTEXT in GcalWindow. Removing this other
notify fixes the crashes related to GcalContext.

#417

Dazzle is very sensitive to returning empty search results,
and ends up flickering when we pass a search model that is
not yet populated.

Wait for a few results, or for 150ms, before returning the
model.

#468

Both --debug and --date had their short form -d, causing
problems. Let's make -d stand for --date, since --debug
is more of a development tool.

#456

Nick Gasson authored Oct 01, 2019 and Georges Basile Stavracas Neto committed Oct 01, 2019

Currently the label text is only updated when set_value is called and
the new value is different to the current value. So if a format callback
is configured after the GcalMultiChoice is created, this won't be
applied until the value is changed to something other than the default.

The problem in issue #100 is that the default value for "month" is
0=>January. gcal_date_chooser_init sets the format callback and then
calls gcal_multi_choice_set_value with value==0 which won't update the
label.

Fix by having gcal_multi_choice_set_format_callback update the label
text with the result of applying the format callback to the current
value.

Fixes #100


(cherry picked from commit b034bd4b)

This already uses an autoptr.

Fixes #455

This improves access to the GcalContext inside GcalManager.

Also, remove test-manager since it only tests that gcal_manager_new()
returns non-NULL.

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

After the next commit, GcalSearchEngine will require GcalContext to be
ready to initialize itself.

The method ask_recurrence_modification_type() currently
receives an ESource, and tried to fetch the ECalClient
from the ESource by using g_object_get_data().

However, since we moved to GcalCalendar, we do not set
this data field in ESource.

Receive a GcalCalendar instead, and use the appropriate
function gcal_calendar_get_client() instead.

Michael Catanzaro authored Sep 14, 2019 and Georges Basile Stavracas Neto committed Sep 14, 2019

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

GNOME Calendar needs to deal with two different
weekday ranges:

 1. Sunday → 0 ... Saturday → 6
 2. Monday → 1 ... Sunday → 7 (used by GDateTime)

When converting (2) into (1), the correct calculation
is `weekday % 7`.

However, gcal_date_time_get_start_of_week() was doing
`weekday - 1` instead.

Fix it and do the correct calculation instead.

#451

#383

Michael Catanzaro authored Jul 17, 2019 and Georges Basile Stavracas Neto committed Sep 03, 2019

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