The color chosen in the new calendar page is currently ignored
when creating a new calendar, as described in #681.
Added a callback similar to that used for the name text entry,
allowing new calendars to be created with the chosen color.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/681
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
This commit updates the dependencies for libhandy to the tagged 1.0
release and changes the code to accomodate the changes from
libhandy-0 to libhandy-1.
Notable changes:
edit-dialog: HdyDialog has been dropped in [1]
alarm-row: action child type in HdyActionRow has been removed.
[1] https://gitlab.gnome.org/GNOME/libhandy/-/merge_requests/434
Cloning an ECalComponent can fail, and we need to be able to
catch these failures.
Assert that cloning was successful before procceeding with
the move.
GcalEditDialog code pre-dates GcalEvent and apply changes directly
to the underlying ECalComponent. However, it doesn't commit the
sequence after doing so, which opens the door for doom.
Commit the component sequence after changing the recurrence data.
When moving an event to another calendar, the GcalEvent instance
that is being held by GcalEditDialog is not valid one. On the other
hand, moving an event shouldn't trigger an update either.
For now, simply fake a GTK_RESPONSE_CANCEL. In the future, it'll
be better to move most of the GcalWindow code to GcalEventDialog
itself.
