The previous approach built tooltip strings by formatting a translated
category name (e.g. "Month") into a generic "Previous %1$s" template.
This is a classic gettext concatenation anti-pattern: languages with
grammatical gender (French, Spanish, German, …) need the adjective to
agree with the noun, and word order can differ from English, so
translators of the format string have no way to produce a correct
result.
Replace the format strings and their helper callbacks with two explicit
GObject properties on GcalMultiChoice: prev-button-tooltip-text and
next-button-tooltip-text. The buttons in the template now bind to
these properties directly. Each widget instance in gcal-date-chooser.blp
sets its own fully self-contained translatable string ("Previous month",
"Next month", "Previous year", "Next year"), giving translators all the
context they need to handle gender and word order correctly.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1547
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/721>
While "7" may be obvious in the context of calendaring that
it represents the number of week days, it often gives me the
impression of it being a magic number when I'm hyperfocused on certain
parts of the codebase for several consecutive hours. Turning the
number into a macro helps me scan functions much more easily.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/674>
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>
Hari Rana