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.
In locales where the first weekday is a monday, the previous code
had a off by one error determining the week a sunday is in.
The problem ultimately arose because in the
`gcal_date_time_get_start_of_week()` function the variable
`n_days_after_week_start` would become negative (-1 in this case) making
the following `g_date_time_add_days (date, -n_days_after_week_start)`
add 1 day resulting in `start_of_week` being set to the start of the
following week.
The solution was to make sure `n_days_after_week_start` would be
positive by adding 7 to it. The variable is taken modulo 7 hence this
should not introduce any bugs.
Fixes#583
Instead of modifying the original event, create a new event
from it and modify this new event instead. After updating it
through gcal_manager_update_event(), GcalMonthView will remove
the old instance and add the new one anyway.
Edit a cloned event instead of the actual event, so that it
can preserve the original event's integrity. This allows for
a major edit dialog cleanup in the future.
