Commit 2d5b1aa9d1 removed the
GCAL_WINDOW_VIEW_DAY variant of the GcalWindowView enum. Since then, the
change-view accelerators to switch to GCAL_WINDOW_VIEW_{WEEK,MONTH,YEAR}
were broken, as the accelerator setup was assuming
GCAL_WINDOW_VIEW_WEEK==1, which isn't true anymore with
GCAL_WINDOW_VIEW_DAY being gone.
This change fixes the enum values in the accelerator setup.
Using dialog responses to communicate intent to GcalWindow was always
a hack, and as the code is cleaned, it's getting increasingly annoying.
Replace this with a proper 'remove-event' signal ('delete-event' would
conflict with the equally named GTK signal), remove the custom response
types, and cleanup the code.
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.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/417
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.
The view knows its time range, and knows what the
next or previous dates should be. So instead of
calculating the next date manually, ask the views
for that.
