UX/UI designed by Philipp Sauberzweig (@PhilippSauberz).
The event editor dialog is now a NavigationView and the participants
details open in a separate page. Group attendees/participants in
AdwPreferencesGroups and bind groups'
ListBox widgets to backing filter models. These are just "views" into a
single GListStore containing all the event attendees.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/671>
Creating "AUDIO" VALARM notification actions causes endless problems:
users may only hear a sound notification (with no visuals), if at all,
and most other apps don't honor nor support editing audio-only alarms.
Other systems typically play a sound automatically on "DISPLAY" alarms.
https://datatracker.ietf.org/doc/html/rfc5545#section-3.6.6 says:
> Multiple mutually independent "VALARM" calendar components
> can be specified for a single "VEVENT" or "VTODO" calendar component.
However, each component states:
> 'action' and 'trigger' are both REQUIRED,
> but MUST NOT occur more than once.
To keep the UI simple, we should pick one or the other; "DISPLAY" it is.
Remove "AUDIO" alarm code and add a warning to never add it again.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1280
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/680>
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>
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>
