Add a pill style to the label of the first day of the month to make it easy to identify. Adjust the border radius of the existing pill style for the current date to be the same. Apply the font-weight using the new style class.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/647>
Change how the template end date is determined by mainly relying on the
new template start date:
- If all day, end date is start date plus 1 day (midnight enforced)
- If time-based, end date is start date plus the time span of the event
properties
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/635>
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>