"event_start" and "event_end" clearly communicate they're the
start and end datetimes of the event. I'm dumb, so I need the
code to tell me what's it about easily.
After adding the EXPLICIT_NOTIFY flag, we needed to make
GcalMonthView notify about it manually, otherwise the
context wouldn't propagate to GcalMonthPopover. We never
did that.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/553
Using raw integers forces us to select a pre-defined
start and end ranges for the timeline. Since we want
to reuse this data structure on GcalTimeline, make it
a bit more useful.
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.
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
self->weather_service was only partially removed in 01fdf79e6a,
leading to a guaranteed crash when the weather is updated because
self->weather_service is now always NULL.
Fixes#397
Instead of assuming all cells have the same width, use the last
cell to figure out the width of the event with the traditional:
event width = end.x2 - start.x1
event width = (end.x1 + end.width) - start.x1
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/413
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.
GcalManager is basically an object that is shared
among classes that need to modify calendars, while
GcalClock is just a wall clock implementation.
Move it to GcalApplication, so that objects without
access to GcalManager can still access the clock.
Event dates are, by definition, inclusive on their
start dates, but exclusives on their end dates. That
means that end dates don't actually contain the date
they represent.
Week grid code, however, was considering that end date
as inclusive, and the layout code was miscalculated
because of that.
Fix that by using an inclusive end date when calculating
the event span. Since Calendar does not support subsecond
precision, we do that by subtracting one second from the
exclusive end date.
Issue: #279
