Previously we had issues on macos where the overshoot would keep showing.
To fix this we need to actually use discrete events instead of the
generated deltas from macOS in the scroll wheel case. Additionally, we need
to drop the kinetic momentum events from macOS and rely on the gtk kinetic
events which are already happening anyway. We also need to submit the
is_stop event for the GDK_SCROLL_SMOOTH case when we detect it.
To keep the discrete scroll events correct, we need to alter the hack in
gtkscrolledwindow.c to use the same path as other platforms except for
when a smooth scroll event is in place. In the future, I would imagine that
this falls into the boundary of high-precision scrolling and would share
the same code paths as other platforms.
With all of these in place, kinetic scrolling with overshoot appears the
same on macOS as other platforms.
The trickery we do with objcopy and ld to speed up
resource inclusion does not seem to work right on
32bit Arm, so just skip it there.
Fixes: #4757, #4748, #4752
We were looking at GtkWidget:has-focus from
event controller signal handlers here, but
the widget property is only changed after
the event controllers.
Update the :has-focus property of the focus
widget when the active status of the window
changes.
We change the property after generating the
GDK_CROSSING_ACTIVE crossing events.
This may come from different sources at around the same time, e.g.
a hold gesture while on overshoot. Avoid doing that if an
animation is already set.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4730
The GtkFileCHooserNativeQuartz injects a NSComboBox into the NSSavePanel
(which is displayed in a remote process since 10.15 whether or not you are
a sandboxed application). The style has changed and we need more space
here to not clip part of the combobox out of view.
I tried every size from 22 to 30 and this seemed to look the most natural
without skewing the location of the text within the combobox.
This makes it easier to figure out those values (which are mentioned in
the GtkApplication documentation) rather than working that out from the
way they're generated (or documented as being generated).
This was causing us to draw the same background content twice which is a
significant amount of bits to flip in the GPU for maximized windows,
especially twice.
This updates GtkPopover to use the new GtkNative abstraction for
reporting opaque regions of the window, in hopes that it can speed
up compositors for things like animated lists, menu transitions,
and more.
Fixes#4689
This switches to using the new GtkNative machinery for updating the
opaque region. Some amount of local calculation is still required for
determining when we should apply shadows, and this inherits what was
done previous for that.
Related #4689
This abstracts the machinery to update the opaque region for a GtkWindow
into GtkNative so it may be used from other native impelementations such
as GtkPopover.
Related #4689
If any of the APIs that assumes that the entry is set already is used
before having one already set, things break pretty badly.
Fixes a downstream issue reported at https://github.com/gtk-rs/gtk4-rs/issues/873