When hovering over the bottom side of a month cell regardless of
the sensitivity state of the overflow button, it queries the
button's tooltip text. Using `gtk_widget_set_child_visible()`
fixes that issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/743>
Since we don't make use of the overlay anymore, it's best to remove
it altogether.
This also changes the behavior of the widgets a bit: It adds an
empty AdwBin widget which expands vertically, allowing us to avoid
aligning the header and overflow button.
The pattern goes from reducible (where we deduct the overflow
height to retrieve the content) to additive (where we add the
overflow height to the content height), which requires us to
adapt GcalMonthViewRow with this new behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/743>
This is future-proofing the uncertain decision of removing
GtkWidget's `margin-*` properties in the future, which is what
we're currently using to retrieve the height of certain widgets.
Whenever the intention is to get the entire size of a particular
widget, including properties that contribute to layout such as
margins, the `get_width()`/`get_height()` methods don't include
these properties during calculations. However, getting the size
of the parent widget will include them in its entirety.
As such, the safest path is to use AdwBin as the parent to the
respective widgets, and using it to retrieve the height.
See: <https://gitlab.gnome.org/GNOME/gtk/-/issues/6556#note_2056432>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/739>
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>
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>
Full month names are easier to notice and read while scrolling,
and would be read more naturally by text-to-speech screen readers.
An exception must be made when today is near the beginning of the month,
as the weather forecast temperatures labels might also appear there.
In that case, use the abbreviated version of the month name label.
Fixes issue #962
If the horizontal space does not allow for an icon and
a temperature label, there'd still be enough space for
an icon only.
Visually, it makes sense to align that icon in icon-only
mode to the end.
Closes: #856
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Co-authored-by: Georged Basile Stavracas Neto
<georges.stavracas@gmail.com>
Now GcalMonthCell handles it internally, instead of receiving the
weather information from the parent view.
This is a modified version of a patch originally written by
camelCaseNick.
The only field that views may change using DnD is the start date
field (and, consequently, the end date), and that's exactly what
we must not show the MOD_ALL option for.
Don't show it.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
Kaiky Cintra