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
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.
The glib-genmarshal tool from GLib 2.54 added various command line
arguments that allow us to remove a bunch of as hoc manipulations of
the generated marshaller source files. The marshal generator tool can
now include an header in the source, and undef the G_ENABLE_DEBUG
pre-processor symbol for us. It can also generate the prototypes of the
marshallers in the C source, and avoid a 'missing-prototypes' compiler
warning.
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
The callback function that is used by VkDebugReportCallbackCreateInfoEXT
is decorated with VKAPI_CALL (which is __stdcall on Windows). This is
not detected on x64 Windows as __stdcall is not really meaningful on x64
Windows, and VKAPI_CALL expands to nothing on non-Windows.
As __stdcall functions are treated differently on 32-bit Windows, the
32-bit compiler does require that the function be declared as __stdcall
so that things will compile, link and run properly.
https://bugzilla.gnome.org/show_bug.cgi?id-773299
Under Wayland, when multiple keys are pressed and the user releases a
key, key repeat should continue unless the key released is the one
currently repeating.
In the case of:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key2 repeat
- key2 release
The behavior should be to cancel keyboard repeat, though key1 is still
held down. This is consistent with prior X11/XWayland behavior.
The following also must work:
- key1 press
- key2 press
- key2 release
- key2 press
- key1 release
- key2 should continue to repeat
The fix for bug #778019 should continue to work:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key2 should repeat
The choice to change the counter nkeys to the flag repeat_active
helps to solve the second test case.
https://bugzilla.gnome.org/show_bug.cgi?id=781285
begin_resize_drag() and begin_move_drag() check for xdg_surface being
not null, but those apply on xdg_toplevel so they should check for
xdg_toplevel being non-null instead.
https://bugzilla.gnome.org/show_bug.cgi?id=781945
When an event is received while a tooltip is showing, the GtkTooltip's
event handling code can end up calling gdk_window_set_transient_for()
from gtk_tooltip_set_last_window().
The Wayland GDK backend will try to automatically create a subsurface
in gdk_wayland_window_set_transient_for() but if the parent surface is
gone meanwhile, this will will cause a crash when trying to create a
subsurface from a parent with a null surface.
Checking for the parent is not sufficient, we ought to check for the
parent surface as well to avoid the crash.
https://bugzilla.gnome.org/show_bug.cgi?id=782283
Applications can specify the type hint as utility even on toplevel
windows.
When that toplevel is also marked as a transient for another window,
GDK Wayland backend would translate that as an xdg_popup which is not
appropriate.
While utility temp windows should remain mapped as subsurfaces (such as
the ones used by treeviews), regular windows should not translate as
neither a subsurface nor an xdg_popup.
https://bugzilla.gnome.org/show_bug.cgi?id=781945
There is no need to have every application log a warning when the
Wayland display server goes away, and we are using _exit instead of
exit elsewhere.
This is also what the X11 backend does (see gdk_x_io_error).
https://bugzilla.gnome.org/show_bug.cgi?id=745289
This just applied to child windows, but now GDK should just take care of
toplevels, which shall get crossing events from the windowing when the right
conditions apply.
Removing this code fixes confused crossing state in widgets and messed up
window_under_pointer tracking (Which now is meant to be toplevels) when any
of the remaining child GdkWindows trigger these crossing events.
For some reason this wasn't done on windows with an impl, but it totally should.
Probably hidden by grabs in menus and somesuch being done on a child window.
As event->any.window is the toplevel, this is not useful anymore to
determine the window/widget that is the target for this event. Add
helper functions to attach user data to GdkEvents so the target
widget can be stored on the gtk/ side.
These calls should be made private with the rest of GdkEvent related
API.
Now that gtk_main_do_event() is able to handle pointing events in toplevel
coordinates, forward all of these as is. Just minimal handling is still done
on the gdk side for GDK grab accounting, and toplevel tracking for each
pointer.
Aborting the application makes it look like an application bug, when
it is the expected thing to do when the Wayland display server goes
way. eg., when the user logs out. The log level is also demoted to
avoid a storm of warnings in the log from all applications whenever
this happens.
This is also what the X11 backend does (see gdk_x_io_error).
https://bugzilla.gnome.org/show_bug.cgi?id=783047
Use the gravity enum values when converting to gravity. It doesn't fix
anything, since the enum values were identical, but it makes a coverity
warning go away.
https://bugzilla.gnome.org/show_bug.cgi?id=780301
The common compiler and linker flags control, among other things, the
default visibility of symbols; without them, we leak symbols that ought
to be private.
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
We can build the name of the input and output files for the Wayland
protocols we use from the protocol name, stability, and version. This is
similar to how the autotools build does it, except much more clear and
without shelling out twice to sed just to resolve the Makefile rule.
