Calling gdk_device_get_direction can trigger a
notify::direction emissions, since the X11 backend
determines the direction on demand. Prevent that by
forcing the direction to be determined ahead of time.
Fixes: #5311
We are caching the bus address as data on the display object when it
exists, but fail to set the data when the bus address doesn't exist.
That causing excessive calls to GetAddress when the accesssbility
bus doesn't exist. Make sure to cache a non-existent accessibility
bus by setting the "" string.
GTK depends on the a11y infrastructure to be in place unless GTK_A11Y is
set to none. It appears that despite that, users attempt to
get around the a11y requirement without setting GTK_A11Y.
This can cause, amongst other issues, performance problems
with gtk applications. Log failure to connect to the a11y
bus.
GLX: Add extra glXMakeContextCurrent () call to work around a DRI issue
Closes#4499, #5387, and #5170
See merge request GNOME/gtk!5285
(cherry picked from commit a9c9678e1f)
f788e994 GLX: Add extra glXMakeContextCurrent () call to work around a DRI issue
GLib 2.74.x and GTK 4.8.x both correspond to the GNOME 43 cycle. Keeping
GLib on the 2.74.x branch avoids a CI regression when GLib git main
depends on a newer Meson version than the one GTK's CI installs, which
has happened in 2.75.x as a result of GNOME/glib!3077.
Signed-off-by: Simon McVittie <smcv@debian.org>
GDK_TOUCH_END deserves the same treatment than GDK_BUTTON_RELEASE, since it's
subject to the same circumstances (popping up a menu on long press would be
immediately dismissed on release if we handled them there). Ideally, we would
want to match releases that we obtained a press for while grabbed, but as
the popup is also dismissed on GDK_BUTTON_PRESS/GDK_TOUCH_BEGIN, there's no
use for this tracking.
And GDK_TOUCH_CANCEL sounds weird as a reason to dismiss popups, just like
crossing events would.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2512
(cherry-picked from commit 2ff4c77c5500110e2b387a8764ab19a92045ff4e)
Even though button 1 (or touch down) presses do most often have
an effect in one way or another (starting drag, moving focus,
starting selection, ...), there is one situation that they do
immediately nothing: When clicking on the entry does not move
the text caret around. Dragging might start a selection, but
the entry did not do anything just yet, and an immediate
button/touch release should remain at "did nothing".
And that is precisely the hint that the Wayland IM context's click
gesture takes, clicks that do not scroll nor move the caret around,
having the GtkText not claim the gesture in that situation makes
the IM gesture able to do its thing without in-fighting.
This is typically not a problem when the GtkText is embedded in
another GtkEditable implementation (e.g. GtkEntry), since the
IM gesture is inactive and capturing from the parent widget, so
gets a pass that it otherwise doesn't get when both gestures are
in the same widget. This makes it work regardless of GtkText not
being a child of a composite widget, like NautilusQueryEditor
and AdwRowEntry.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5351
(cherry-picked from commit 09b982f0264e42bda3e8471bb25abec5ee742ecc)
When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.
This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5250
8455b9ac74 seems to have introduced a problem where we can wind
up focusing no widget at all if the `while (parent)` loop doesn't
find a widget it can successfully move the focus to. This 'fixes'
that by falling back to doing the previous thing if we make it
all the way through that loop without moving the focus. Thanks to
@coreyberla for a hint to improve the implementation.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
GTK knows when a surface is modally blocked and automatically drops
button press and release events, so do not block input in advance
from WM_MOUSEACTIVATE.
