The window would either set focus to the event widget or a
focusable ancestor, no matter how the event popover was being
closed.
This caused a major accessibility regression where,
whenever the event editor dialog opened from the event
popover, the window set focus to the event widget instead of
the content inside the dialog, which made the dialog incapable
of navigating through until the dialog was focused. This also
prevented mnemonics from being triggered.
This patch addresses that bug by only setting focus whenever
the popover is being closed explicitly; as in, when the user
presses outside the popover to hide it or pressing escape.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1398
GcalRecurrence is shared/mutable. So, if we have
curr.recur = ref(event.recur)
orig.recur = ref(curr.recur)
then recurrence_changed() will return false, since both orig.recur and
curr.recur will point to the same object. We need fresh copies.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
Apparently the calendar's views hold a live event editor without an
event, and only set an event when one is selected for editing.
I think it would simplify things to only create the event editor when
it is actually needed, with an event - it would avoid these checks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
This commit does a bit too much, but with these themes:
- Move the recurrence fields into GcalScheduleValues. This was needed
for consistency, anyway, and...
- ... the next step was to make ::changed() work, which actually
required knowing the original and current values of the recurrence as
well as the dates.
- But then, having a field "orig_foo" for each field "foo" starts
getting unwieldy. So, I moved things around:
- GcalScheduleValues has start/end dates and all_day, and the recurrence.
- GcalScheduleSectionValues is new; it has the "orig" and "curr"
values of the previous type. This simplifies memory management
since each field can be freed with gcal_schedule_values_free()
instead of duplicating _free() for each sub-field.
- GcalScheduleSectionValues also has time_format, as a way to
decouple that value from GcalContext. It's not in orig/curr
because it does not pertain the event; it's just a display-related
thing.
- Actually fix gcal_schedule_section_changed(),
gcal_schedule_section_recurrence_changed(), and
gcal_schedule_section_day_changed(). These become simple since they
just look at the orig/curr fields, without having to touch widgetry.
- All test pass.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
The original code from commit 10234653 is
GCAL_RETURN (gcal_date_time_compare_date (start_date, gcal_event_get_date_start (self->event)) < 0 ||
gcal_date_time_compare_date (end_date, gcal_event_get_date_end (self->event)) > 0);
but it doesn't explain why it just checks for the modified event
getting "wider" (earlier start, later end) than the original event.
I don't understand that logic, i.e. why doesn't it just check that the
dates changed.
Still, now that we keep the original date-time in the
GcalScheduleValues, use them to preserve the original semantics.
I'm not sure exactly what to test about this... a test to preserve those
semantics? A test that the function, per its name, returns true if
the days are strictly different?
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
That is, we'll keep the original values, plus the working values that
get changed from the widgets. We'll use the original values to be
able to reconstruct the original event's duration if needed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
I want to test that when:
- a one-hour event is loaded
- all-day is turned on
then the start and end date widgets display both the same date.
This fails right now, because we subtract one from the end_date. I'll
change the way the dates are handled so that this magic only needs to
be done when setting back the GcalEvent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
This clarifies things:
* GcalScheduleValues contains the real data, based initially on the
GcalEvent.
* WidgetState's date_time_start / date_time_end may not be the same as
the real data, since the values get adjusted for display, as in the
case when handling all_day events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
