This adds support for the shortcut inhibitor protocol in gdk/wayland
backend.
A shortcut inhibitor request is issued from the gdk wayland backend for
both the older, deprecated API gdk_device_grab() and the new gdk seat
API gdk_seat_grab(), but only if the requested capability is for the
keyboard only.
https://bugzilla.gnome.org/show_bug.cgi?id=783343
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
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
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
Allow getting the same export handle multiple times by calling
gdk_wayland_window_export_handle() multiple times. For each time
export() is called, a unexport() must be called to unexport.
When the window is already exported, the exported callback is called
via a idle handler. If there are multiple export() calls, they are
invoked in order either when the handle is received by the display
server, or when the idle callback is invoked.
Calling unexport() will not affect future invokations of the exported
callback, unless all export() calls have their unexport() call count
matched.
https://bugzilla.gnome.org/show_bug.cgi?id=782325
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
With Wayland, GDK_DEBUG=events would log key events but not explicitly
state whether the event is a key press or release, or if it's
originating from a key repeat.
Add some more verbosity to make sure these informations are logged on
key delivery when GDK_DEBUG is set.
https://bugzilla.gnome.org/show_bug.cgi?id=781767
It is generally a good idea to license individual files under the
same terms as the project license (in particular when the mismatch
boils down to having copied the wrong license header), so relicense
the code under the LGPL.
https://bugzilla.gnome.org/show_bug.cgi?id=781422
Make sure to clear up the number of keys being pressed on enter/leave so
that we don't end up with leftovers if a new window is mapped by a
keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=779374
The key repeat is stopped as soon as a key is pressed, so if the user
quickly presses a key while another is already pressed and being
repeated, key repeat gets cancelled:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key 2 is not repeated even though it's kept depressed
This is a different behavior from X11, which confuses migrating users.
To mimic the X11 behavior, keep track of the number of keys pressed
simultaneously and cancel key repeat only when none is pressed.
This way, if a user pressed a key while another one is being repeated,
the new key press can possibly be repeated as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=778019
When resizing an xdg_popup immediately after the initial mapping, there
is a race condition between the client and the compositor which is
processing the initial size given by the xdg_positioner, leading to the
xdg_popup to be eventually of the wrong size.
Only way to make sure the size is correct in that case is to hide and
show the window again. Considering this occurs before the initial
configure is processed, it should not be noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=772505
Clamping the anchor values as introduced in commit 9a5ffcd to fix bug
777176 breaks menu positioning.
By keeping the anchors rectangle size greater than zero, we end up
deducting some positive value from the original position, so there is no
need to clamp() actually, keeping the values positive is enough and
avoids the issue with menu positioning on the menubar.
An additional benefit is to make the code a lot simpler.
https://bugzilla.gnome.org/show_bug.cgi?id=778009
Currently hiding destroys the wl_surface and all related interfaces,
(including the gtk_surface1) so the next time the GdkWindow is mapped,
we don't bother to set the DBus properties. Toggle the check off so
it's actually issued again after the GdkWindow gets a gtk_surface1.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
This is how windows are meant to be hidden as per the wayland
protocol, there's no need to destroy the xdg_surface and other
interfaces.
Also, rename gdk_wayland_window_hide_surface() to clear_surface(),
as that's what it does.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
Elsewhere we already go through the keymap to get modifiers so we
should do the same here. In fact, this was relying on xkb modifier
mask values being bitwise compatible with GdkModifierType which isn't
necessarily true.
https://bugzilla.gnome.org/show_bug.cgi?id=770112
Gtk+ treats MOD1 as a synonym for Alt, and does not expect it to be
mapped around, so we should avoid adding GDK_META_MASK if MOD1 is
already included to avoid confusing gtk+ and applications that rely on
that behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=770112
Passing a rectangle with zero width or height to xdg_shell-v6
set_anchor_rect() will cause a protocol error and terminate the client,
as with gedit when pressing the Win key.
Reason for this is because the rectangle used to set the anchor comes
from gtk_text_layout_get_iter_location() which uses the pango layout
width/height, which can be empty if there is not character at the given
location.
Make sure we don't use 0 as width or height as an anchor rectangle to
avoid the protocol error, and compensate the logical position of the
given rectangle if the size is changed, so that the actual position
remains as expected by the client.
https://bugzilla.gnome.org/show_bug.cgi?id=777176
We have a frame clock that ensures rendering is done as per the
output vsync. There is no need to have Mesa do the same for us.
This, most notably, ensures Mesa doesn't schedule frame callbacks
that will be left unattended if the compositor stops throttling
frames for its surface, this is eg. the case if the toplevel is
moved to another workspace.
Also, given a SwapInterval!=0 will always bring these unexpected
side effects, check that it's possible to disable it, and spew
a debug message if that isn't the case.
https://bugzilla.gnome.org/show_bug.cgi?id=769835
If there are no targets, DnD is probably intended to be local,
add a mimetype for matching then. The wayland protocol requires
at least one wl_data_offer.target call with the mimetype selected
for transfer.
When a subsurface is used as a parent of a popup, GDK needs to traverse
up to the transient-for as the next parent, to properly find the parent
used by the popup positioner. This is because the parent of a popup
must always either be an xdg_popup or an xdg_surface, but traversing
the "parent" (in GDK terms) upwards from a subsurface will end up on
the fake root window before we hit the actual parent (in Wayland terms).
https://bugzilla.gnome.org/show_bug.cgi?id=776225
For subsurfaces, the new state which includes the input shape is not
applied by the compositor if the subsurface is in effective synchronous
mode.
So we need to apply the input shape once parent surface is in effective
desynchronized mode, which is when it's committed, otherwise the input
shape may never be applied if the widget is not using being_paint() /
end_paint() to draw on its subsurface, like clutter does.
We do that only for empty input shape as those won't need update when
the subsurface is resized, for all other non-empty input shape, the
client still has to use begin_paint()/end_paint() for the input shape to
be applied.
https://bugzilla.gnome.org/show_bug.cgi?id=774534
Now that subsurfaces can be created as child of another GdkWindow (and
not just the root window), they must be placed according to the location
of their parent, i.e. the abs_x/abs_y must be updated and taken into
account when placing and moving subsurfaces under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=774917
This can be triggered on workspace switches, and on hidpi results in
the scale factor being reset to 1 while the window is not in the
current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=774476
For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
gdk_wayland_window_attach_image() is normally called from
gdk_window_end_paint() to notify the compositor of newly staged drawing.
If any of the drawing code inadvertently dispatches the wayland event
loop (for instance with a gdk_flush() call), then it's possible that by
the time gdk_window_end_paint() is called, the staged drawing is already
destroyed.
This commit bypasses the attach_image call in scenarios where the staged
drawing is prematurely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=773274
