This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
This property contains 5 integers, of which the last 2 respectively
contain the tool serial number and tool ID. We were only extracting the
first so far, but GdkDeviceTool also has API getters for the latter,
which remained 0.
https://bugzilla.gnome.org/show_bug.cgi?id=786400
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
There was a return between a push/pop of an error trap, and
this managed to trigger the 'unpopped trap' warning in the
displayclose test now. Fix this.
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
The virtual host assigns the name of the mouse device to
"VirtualBox USB Tablet" in VirtualBox and we'd use that device as mouse.
If not, GtkTooltip is not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=763017
Sigh.
Now that we've neutered the QEMU USB tablet, I'm finding that
spice is doing just the same nonsense. It has a fake "spice vdagent
tablet". Blacklist that as well.
Commit 1266d15c4 also broke Xwayland, as it does the same trick
than VMWare pointers. Let's extend the heuristic to check for "pointer"
in the device name, what can possibly go wrong...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
VMWare seems to create mouse devices with abs axes which confuses
our detection of single-touch touchscreens. Those have though a
name we can match on ("VirtualPS/2 VMware VMMouse"), it should
be pretty safe to assume that no real touchscreens have "mouse"
in their name...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
Those won't have ABS_MT_* axes, so won't be reported has having
XITouchClassInfo. Fallback on these to checking whether abs x/y axes are
available. After the Wacom checks, any remaining device with absolute axes
should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on
devices with relative axes.
https://bugzilla.gnome.org/show_bug.cgi?id=757358
Otherwise the outer loop control variable is messed up, and we end
up with uninitialized axes if there were any more valuators after
the XIKeyClass one.
This bug was sneakily introduced by fdb9a8e14, many thanks to
Carlos Soriano for helping spot the source of this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=753431
We used to "invalidate" scroll valuators, so the next scroll event could
be used as the base for the next scroll deltas. This has the inconvenience
that it invariably consumes the first event received after enter and,
due to interactions with WM overeager passive button grabs, there's a
possibility we don't scroll at all if we receive interleaved "smooth
scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
scroll wheels in mice).
In order to fix this, and at the expense of some sync-call overhead on
XI_Enter events (one XIQueryDevice call per slave device), query the
current scroll valuator state for all the slaves of the entered pointer,
so we do know beforehand the right base values. If new devices are plugged
while the pointer is on top of the client, the initialized scroll values
will match the valuators'.
https://bugzilla.gnome.org/show_bug.cgi?id=750994https://bugzilla.gnome.org/show_bug.cgi?id=750870
And use these for the missing axes if the valuator mask is incomplete.
This used to work fine on tablets because the Wacom driver ensures all
valuators are sent, which is not true if using the evdev driver.
https://bugzilla.gnome.org/show_bug.cgi?id=703610
This fixes potential assertions if a GTK+ app gets to receive
a XINotifyPassiveGrab/Ungrab pointer crossing event, currently
triggerable by XIGrabEnter passive grabs.
http://bugzilla.gnome.org/show_bug.cgi?id=719762
Scroll valuators were being just appended again and again, leading
to 1) a growing memory issue anytime a device changed 2) the first
scroll valuators to stay permanent on the application lifetime, as
the first stored valuators would always match.
https://bugzilla.gnome.org/show_bug.cgi?id=705203
Passive grabs may take pointer focus out of the application, even though
the pointer didn't leave the window, but those events still trigger resetting
of the scroll axes. This is most visible with compiz, and possibly other
reparenting WMs, where passive grabs happen on the WM-managed window that
is a parent of the application toplevel.
As it is not possible to have scrolling happening on the timespan a passive
grab takes action, it is entirely safe for GTK+ to assume none happened if
it gets a crossing event of that nature.
https://bugzilla.gnome.org/show_bug.cgi?id=699574#c33
This information will be useful in case someone stumbles on a situation
similar to https://bugzilla.gnome.org/show_bug.cgi?id=699574, so we can
figure out where do the crossing events come from or go to easily.
