Ctrl+scrolling with a mouse wheel zoomed in the opposite direction
than expected: scrolling up zoomed out and scrolling down zoomed in,
which is inconsistent with other GNOME apps such as Loupe and
Nautilus.
Negate the scroll delta in both smooth (touchpad) and discrete
(mouse wheel) scrolling cases, so scrolling up now zooms in.
Fixes#1633
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/815>
Before, two finger scrolls on mint cinnamon (X11 scroll instead of
wayland) caused month view to crash. g_clear_obj... orphan would an
animation allowing two animations to exist at once, causing conflict
when the orphan continued in the background. The two animations would be
generated due to X11's legacy support of both discrete notch scrolling
and the two finger smooth scrolling.
I replaced g_clear... with cancel_row_offset_animation in
snap_to_top_row which ensures that the orphaned animation is dead prior
to reassigning variables.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1616
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/801>
The gnomeos-basic-ci component already has support for gobject-linter
and we only need to add a config file to make it run and show up as
part of a merge request's code quality check.
I set the property enum convention to "legacy", as that is the style
we currently use. Since this is only a matter of style, I do not see
the point in changing all (>40 occurrences) of that just because.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/799>
When an event widget is focused, there is no way to skip the entire
view with key combinations.
This patch addresses this by allowing the user to skip the entire
view when pressing Ctrl+Shift+Tab.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/817>
Visually, this comes with the benefit of not having the first
and last visible event widgets take additional margins, as spacing
is only applied between event widgets.
This will also allow us to make use of gtk_widget_pick() without
having to rely on hardcoding 1 on the y axis.
The current approach has a one pixel margin at the top and bottom
of each event widget, which offsets the vertical position of
every event widget by one pixel. In order to pick the first
event widget, we'd want to call
gcal_month_cell_get_header_height() because this is where the
first event widget is placed. If we were to invoke
gtk_widget_pick() with (x, 0), where x is
half the width of the month cell, the returned value would be
NULL because gtk_widget_pick() does not account for margins,
so it would need to be (x, 1), with 1 hardcoded.
Since this patch removes that offset, we can simply use
(x, 0) without having to hardcode 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/813>
For unknown reasons, the `::row-activated` signal is not emitted
whenever the user presses an activation button on the keyboard
such as Enter or Space, even though the list box row has focus.
Ideally, we want the list box rows to be activatable, so that
activating them will simply emit the "event-activated" signal and
pop up the popover.
Since this doesn't work, the next best thing is to make the event
widgets themselves focusable and the list box rows unfocusable.
This will unfortunately lose the ability to navigate with arrow
keys, as well as Home/End and Page Up/Down. However, the user will
at least be able to activate them and access events in
the agenda view.
A `FIXME` label has been added because this should be fixed as soon
as possible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/807>
Balázs Úr