When opening the event editor dialog as a new event, `set_new_event_mode()`
immediately tries to focus the last focused widget, which won't work
because it is unfocusable. `focus_last_focused_widget()` then clears
clears the pointer regardless of whether the widget has successfully
grabbed focus or not. So, we want to only clear focus if the widget
has successfully grabbed focus.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1566
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/730>
The event popover contains a lot of text in different sizes, which
pushes us to magic-number the maximum amount of characters
(i.e. `max-width-chars`) and hope that all is well.
This approach addresses that by simply clamping the parent widget
to the desired size, allowing us to remove all instances
of `max-width-chars`.
Do note that `Adw.Clamp:tightening-threshold` is set to 400 by default,
which technically doesn't need to bind to `Adw.Clamp:maximum-size` at
the moment, but I decided to do it anyway in case we want to change
`Adw.Clamp:maximum-size` in the future and can't figure out why
the margins are off.
Co-authored-by: Jamie Gravendeel <me@jamie.garden>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/728>
This fixes an issue where pressing Shift + Up/Down while focused on the
overflow button will result in a bail out when asserting the focused
widget has a month cell ancestor:
```
GcalMonthView:ERROR:../src/gui/views/gcal-month-view.c:1002:on_key_controller_key_pressed_cb: assertion failed: (GCAL_IS_MONTH_CELL (month_cell))
Bail out! GcalMonthView:ERROR:../src/gui/views/gcal-month-view.c:1002:on_key_controller_key_pressed_cb: assertion failed: (GCAL_IS_MONTH_CELL (month_cell))
```
When navigating between month cells with a keyboard, focus is set
on respective month cells, so checking whether the ancestor
is a month cell or not is not only unnecessary, it also causes
bugs like the assertion above.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/720>
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>
Without this patch, focus immediately goes to the "Previous Month"
button at startup, for some unknown reason.
So, as a workaround, skip focus if the root cannot retrieve the
current focused widget.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/564>
Hari Rana