The entire dialog is wrapped under a scrolled window, it
doesn't make much sense to have yet another one for the
notes. This is a relif of times when the edit dialog didn't
have a scrolled window.
Remove the scrolled window of the notes section.
We want them to grow a bit more, and not let the expansion
of the title label detemine the width. Allow the location
and title entries to expand, and set a maximum width char
to 30 on them.
See https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/554
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.
In on_calendar_monitor_completed_cb() we have this assert:
g_assert (self->completed_calendars <= g_hash_table_size (self->calendars));
That is comparing a signed integer to unsigned. This is dangerous. We
could add casts to say that we really want to do it, but
completed_calendars should never be negative, so might as well use
unsigned.
Since 78cb11c64d, GcalCalendarMonitor now
notifies when a completed calendar transitions to incomplete, and
GcalTimeline decrements its completed_calendars counter. But we forgot
to remove the code that resets completed_calendars when previously
needed. That's not required anymore, because we can trust
GcalCalendarMonitor to do the right thing.
In my case, I have 5 calendars enabled and 6 total. When starting
gnome-calendar, all 5 are successively completed, and
completed_calendars increments from 0 -> 1 -> 2 -> 3 -> 4 -> 5. Then,
when transitioning month view from January 2020 to December 2019, we
call reset_completed_calendars() and completed_calenders gets clobbered
to 0. Then it decrements from 0 -> -1 -> -2 -> -3 -> -4 -> -5 as the
GcalCalendarMonitors notify that they are no longer completed. Well,
that is what would happen, if it didn't crash when decrementing to -1.
We assert -1 <= 6 (the total number of calendars) and crash because -1
gets promoted to a huge unsigned int, since we're comparing signed to
unsigned. (That crash would have been avoided if we used
-Wsign-compare, although that warning would not have caught the logic
problem.)
Anyway, since GcalMonitor now notifies when calendars are no longer
complete, it is safe to simply remove reset_completed_calendars().
GcalTimeline will still notify if it needs to change its own complete
property (in on_calendar_monitor_completed_cb).
Fixes#567Fixes#636Fixes#638Fixes#647Fixes#650
