Store a list model of attendees inside the event editor dialog and use
this model when displaying the details page. The attendees section (like
other sections) gets injected with the event and gets another copy of
the attendees from the event. Both the section and the details page can
now avoid resetting themselves when the underlying data (event) doesn't
change. Note: the details page uses a ListBox for the sake of the UI
style, which can underperform with a lot of attendees (building the
visual tree can be laggy).
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/671>
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>
Hari Rana