GcalEventPopover gives a preview of the event, and handy access
to the event description and information. It also allows easily
joining meetings if any one if available.
The list of supported meeting URLs is small now, but I hope
more people will contribute as we go.
It is also possible to edit the event through an edit button.
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.
