We can e.g. get the entry dispose()d and a focus_out event after that
(because the toplevel unsets the focus which previously was the entry).
We then later use priv->current_pos in a call to pango API which makes
sure the given index is valid for the given layout. Since we lazily
create a GtkEntryBuffer in get_buffer() and a PangoLayout lazily in
gtk_entry_create_layout, these 2 are always valid but don't match
priv->current_pos in this situation.
Fix this by resetting priv->current-pos in dispose().
https://bugzilla.gnome.org/show_bug.cgi?id=785255
There's GDK grab situations (eg. pointer motion outside the grab window
in combination with a GTK+ grab) where a gesture may receive events from
windows that are not the widget's.
The _update_widget_coordinates() still does work for those situations, so
just let these events go through instead of ignoring them.
https://bugzilla.gnome.org/show_bug.cgi?id=782870
Refactor the code updating the active link under the current coordinates
into a separate function, and call it on GtkGestureMultiPress::pressed
so the link is updated on GDK_TOUCH_BEGIN. Based on a patch by
Jan-Michael Brummer <jan.brummer@tabos.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=776903
Setting the cursor on the widget window (i.e. the parent widget's) is
finicky because the cursor needs to be updated on crossing events, and
will yield the wrong result for other master devices that happen to be
in other areas of the same parent widget's window.
Just set it always on the event window created by the GtkButton parent
class. That window was causing the crossing events, so the rectangle
that gets the hand cursor set will be the same size, and we don't need
to track pointer crossing state that way.
https://bugzilla.gnome.org/show_bug.cgi?id=785375
This check must be done explicitly on Wayland as the master device for
tablet tools differ from the Core Pointer. This ensures that whenever a
tablet tool is inside a window and the cursor is programmatically changed,
it will be visually updated too.
https://bugzilla.gnome.org/show_bug.cgi?id=785375
Adds support for creating scroll events from Wayland tablet wheel events.
Even though no Wacom tablet puck has a smooth-scrolling wheel, both event
types need to be generated to make the upper layers happy.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
If a tablet device is used to perform actions like window moving or resizing,
GTK must provide the correct implicit grab serial number over Wayland to Mutter
in order for the action to succeed. This commit adds tablet support to the
implicit serial getters.
https://bugzilla.gnome.org/show_bug.cgi?id=777333
If a bad behaving application tries to make the window/display beep too
often, throttle the beep requests so that we don't end up filling the
Wayland socket queue.
The throttle is set to 50 beeps per second, which far more beeps than
will ever make any sense from a user experience point of view, but will
avoid terminating due to an excessive amount of requests.
https://bugzilla.gnome.org/show_bug.cgi?id=778188
Pixdata is deprecated but some software already use GtkImage widgets
with image data loaded from GResource-backed pixdata. As the
security-problem ridden pixdata loader was removed, we need to manually
check whether the GResource data is pixdata, and load it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=781583
Use the new predictable request object path and connect
to the Response signal before issuing the portal call.
This avoids a race that is pretty unlikely to hit in
the filechooser case.
Wacom tablets often have a "pad" device which houses multiple buttons. At
present, these devices are incorrectly marked as GDK_SOURCE_PEN which can
cause problems for some software.
https://bugzilla.gnome.org/show_bug.cgi?id=782040
