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
It is not necessary to (re)set the cursor on every crossing
event, and can probably yield the wrong results if there are
multiple master devices involved. Just set it on init(), and
let the inner machinery update the cursor whenever necessary.
This patch is an adaption of commit 0daf79676 in gtk-3-22, the
side effects are not as bad here because the cursor was already
being set on the widget specifically instead of the parent
widget's, but there's still some nonetheless (plus, it's simpler)
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
Replace uses of VLAs (variable-length arrays) using g_newa(), since
Visual Studio builds will unlikely ever support VLAs (which became optional
in C11).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
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
Since gtk_bin_add does a gtk_widget_set_parent call, we cannot use it in
a GtkBin implementation that has multiple child widgets and cares about
their order.
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
So we can avoid creating a GtkCssPathNode in _init and then throwing it
away right after when using the _new_with_node constructor, which is the
one we use for all widgets.
Don't set the have_focused field of the window's toplevel to TRUE by
default and don't set the FOCUSED state in gdk_window_map. This a means
toplevel window's state is what the WM expects, and the FOCUSED state
will be set anyway when we map the window and receive a _NET_WM_STATE
message.
