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
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
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.
Using GLists and GSLists is a bad practice. These data
structures are too much inneficient and GPtrArray has
the advantage of having a free function pointer, so we
can hide the underlying free function from the consumers
of this API.
This also gets rid of another allocation cycle in Month
view.
This commit triggers two existing issues:
1. window size calculation
(this breaks month-cells)
2. wrong reference counts in views
(I use :destroy to avoid dangling pointers)
This is another major reorganization of the Month view's
allocation code. The goal is not to reduce the number
of lines, but to make them readable and maintainable.
During this reorganization, multiple bugs that were never
hit were ironed out! That itself would be a major win, but
since the code is actually more readable, we can expect
more improvements from now on.
This removes much of the subtle complexities of the size allocation
function in month view, and finally delivers a readable and working
implementation of the month view.
This also introduces a small code refactoring, and fixes clicking
on a cell on RTL.
Multiday event handling was a mess, and still it. But this commit
makes it at least layout things correctly.
It's not perfect, though; This commit brought back that terrible
allocation cycle issue, since we're showing and hiding events in
size-allocate.
