Commit Graph

1052 Commits

Author SHA1 Message Date
Florian Müllner
da8f634b25 gdk/wayland: Support new high-contrast key
We now have a boolean setting that determines whether the high-contrast
theme should be used. Support it by automatically setting the existing
`gtk-theme-name` and `gtk-icon-theme-name` properties when enabled.

With that, it is no longer necessary to change the regular theme settings
for high-contrast, so toggling between high-contrast and a non-default
theme finally works reliably.
2021-12-21 14:01:10 +01:00
Carlos Garnacho
068df4874a Merge branch 'wayland-clipboard-fix' into 'gtk-3-24'
wayland: Ensure clipboard handling doesn't lock up in certain corner cases

See merge request GNOME/gtk!4058
2021-12-06 11:16:54 +00:00
msizanoen1
e23b4dd21b wayland: Ensure clipboard handling doesn't lock up in certain corner cases
When a selection request fails to be converted to the requested format in the
GTK layers, the wayland backend would miss bumping the machinery to handle
further pending selection requests. Fix this by reacting to
GdkDisplay::send_selection_notify with target=GDK_NONE (i.e. a failed
conversion as hinted from the upper layers) to do that.

This ensures the clipboard handling doesn't lock up in the following
scenarios:
  - GTK returned with a mismatching type to the one requested
  - GTK fails to convert to the requested type

Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4340
2021-12-06 11:30:11 +01:00
Carlos Garnacho
d81f58bc09 gdk/wayland: Do not use xdg_wm_base.ping serials as "user input" serials
Ping/pong serials are not meant to be interpreted as user input serials
(e.g. those given back later to the compositor on grabs). As a matter
of fact, Mutter uses a different count (i.e. timestamps) in these, so
using these serials may confuse the compositor into denying certain
operations like DnD.
2021-11-05 14:43:23 +01:00
Matthias Clasen
25d01b7610 Merge branch 'wip/fix-remap-up-left-popup' into 'gtk-3-24'
window/wayland: Reset position when hiding popup

See merge request GNOME/gtk!3913
2021-10-18 22:34:39 +00:00
Ronan Pigott
23c7e6e13b Check if size changed before hiding a surface
Commit 68188fc948 introduces a workaround for clients that try to
change the size of a popup after it is created, but inadvertently
introduces an infinite loop of surface creation when the popup enters
two or more wl_outputs with different scales on creation.

This commit checks if the size actually changed before applying the
workaround and avoids the loop.
2021-09-13 17:14:14 -07:00
Ronan Pigott
9a4e328928 Ignore wl_output globals not bound by us
Gdk doesn't know the scale of output globals it didn't bind. This
keeps them from entering the output list and triggering erroneous
changes in surface scales.
2021-09-13 03:08:49 -07:00
Jonas Ådahl
d74b01636b window/wayland: Reset position when hiding popup
When a popup is remapped, if the GdkWindow::x/y position is negative,
some best-effort hueristics used to ignore internal X11-style hackery
windows incorrectly scooped up remapped popup windows.

Avoid these hueristics by resetting the x and y fields of GdkWindow to 0
whe hiding a popup. It'll then appear as if it was newly initialized,
and escape the mentioned hueristics.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4071
2021-09-02 10:24:38 +02:00
Vlad Zahorodnii
92ba4bf396 gdk/wayland: Fix pointer-gestures version selection
version == GDK_ZWP_POINTER_GESTURES_V1_VERSION will fail if the
compositor implements version 2 of pointer-gestures-v1.
2021-07-05 14:50:59 +02:00
Guido Günther
8c0b11998d gdk/wayland: Take transform into account when setting physical size
Width and height of a GdkMonitor are derived via wl_output which
talks about physical dimensions of a device and compositors usually
implement this as the untransformed values (e.g. weston, wlroots).

Since the GTK client has no way to figure out if a monitor was rotated,
transform the physical dimensions according to the applied wayland
transform to have the physical dimensions match the logical ones.

Mutter flips the physical dimensions itself but doesn't announce the
transform so this shouldn't break anything there.
2021-05-05 18:09:07 +02:00
Matthias Clasen
dfea8c31d9 wayland: Improve font setting fallback more
We may get a response from the portal that contains
no useful settings at all. In that case, we should
fallback as well.

Fixes: #3838
2021-04-07 14:30:48 -04:00
Matthias Clasen
a3ff6e279c wayland: Improve font setting fallback
When we don't get stettings from the portal, the current
fallback is 'awful fonts'. There is no need for that. Instead,
set the fallback values to grayscale antialiasing with slight
hinting.
2021-04-07 08:43:08 -04:00
Robert Mader
86ef0e6094 gdk/wayland: Defer processing of globals closures
... until all globals have been received.

The dependency tracking introduced in 4e9be39518 only allows to
specify required globals and processes the closures as soon as
the requirements have been met. There are, however, also optional
dependencies - most notably the primary_selection protocol.
Currently we rely on the fact that compositors like Mutter announce
it before `wl_seat`, even though the order is not specified in
the spec.

Process globals closures only after all globals have been announced,
so optional dependencies can be accommodated.

Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/3791
2021-03-30 15:10:04 +02:00
Matthias Clasen
1ce5494ffd wayland: Pass layout information in key events
We were always setting group to 0, causing accelerator
interpretation to always go off the first configured
layout, not the active one.

Fixes: #1825
2021-03-15 14:48:05 -04:00
Carlos Garnacho
4d30400987 gdk/wayland: Look for font settings recursively
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.

Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
2021-02-18 16:51:28 +01:00
Robert Mader
d3316a37ed wayland/window: Add API to add extra surfaces for frame callbacks
This is useful when clients use subsurfaces independently of GDK.
For example if a client creates a subsurface that covers a GdkWindow
entirely. If this subsurface is opaque, Wayland compositors may not
emit callbacks for the surface of the GdkWindow any more.
Adding the covering subsurface via this new API ensures the
GdkWindow will continue to update in this case.
2021-02-12 13:18:29 +01:00
Jonas Ådahl
ddb9bae3d4 Merge branch 'gtk-surface-release-3-24' into 'gtk-3-24'
Support gtk-shell surface release destructor

See merge request GNOME/gtk!2074
2021-01-29 16:21:09 +00:00
Carlos Garnacho
02a02fac56 gdk/wayland: Mark matched settings from the portal as valid
Commit e6209de962 added some checks on TranslationEntry.valid in
order to figure out whether using the new font settings or the
old g-s-d ones. However that's only set in the non-sandboxed case.

This makes sandboxed applications fallback to the old (and also
non-existing with modern g-s-d) settings, possibly resulting in
ugly defaults being picked.

Fix this by also marking TranslationEntry elements as valid when
using the settings portal, precisely those entries that we are able
to read and match with our own table.
2021-01-14 16:09:27 +01:00
Carlos Garnacho
7ab4c9a68b Merge branch 'fix-tablet-3.24' into 'gtk-3-24'
Wayland: Fix segfault when receiving tablet/touch events for surfaces that have already been destroyed client-side

See merge request GNOME/gtk!2809
2021-01-10 13:18:15 +00:00
wisp3rwind
19a740e277 Wayland: ignore touch/tablet events on destroyed surfaces
When destroying a wl_surface (e.g. when a window or menu is closed), the
surface may continue to exist in the compositor slightly longer than on
the client side. In that case, the surface can still receive input
events, which need to be ignored gracefully.
In particular, this prevents segfaulting on wl_surface_get_user_data()
in that situation.

Reported in
https://gitlab.gnome.org/GNOME/gtk/-/issues/3296

The same issue for pointers/keyboards was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=693338

and fixed with in
bfd7137ffb
3625f17857
a8fc099a72
2021-01-10 12:00:28 +01:00
Carlos Garnacho
cae5e60113 Merge branch 'avoid-pointer-reset' into 'gtk-3-24'
wayland: avoid set_cursor() when unchanged or invisible

See merge request GNOME/gtk!2822
2021-01-06 19:53:30 +00:00
wisp3rwind
cf7f7df10c wayland: avoid set_cursor() when unchanged or invisible
In pointer_surface_update_scale(), only rescale the cursor surface when
the scale has actually changed and the cursor is on at least one output.

fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3350

Right now, this issue is not completely understood, so it might also
involve some questionable handling of cursor surface by sway/wlroots.

However, irrespective of that issue, this patch avoids unnecessary calls to the
compositor, and there should be no drawback: Whenever the pointer enters
a new output, pointer_surface_update_scale() will be called again, such
that correct scaling of the cursor is still ensured.

There is a slight difference: When the cursor leaves the last output,
previously the image was reset to scale factor 1. Now, it keeps whatever
was last. That might be more sensible than the previous behaviour,
assuming that it's likely that when the cursor enter an output again, it
has the same scaling. Alternatively, if one cares about resource usage
at this level, it might make more sense to destroy the surface then
rescaling to 1.
2020-11-13 16:20:02 +01:00
Jonas Ådahl
ba31560970 wayland: Bail loudly if invalid geometry is set
There is some bug somewhere where the geometry ends up being correct.
Mutter didn't handle this gracefully, and is to be changed to simply
respect the protocol and error out the client that sends bogus data.

Prepare for this by instead of sending bogus data, complain loudly if it
would happen dropping the invalid geometry on the floor instead of
sending it.

Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1527
2020-11-11 10:17:59 +01:00
Robert Mader
5bd8f8c5a3 gdk/wayland: Add support for primary-selection-unstable-v1
Additionally to gtk_primary_selection, the gtk-private predecessor,
support the upstream unstable protocol.

This allows the primary selection to work on Kwin and potentially
other compositors, as well as dropping the private version eventually.

Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2591
2020-09-27 13:40:40 +02:00
Jonas Ådahl
a184b5bf51 wayland: Emit dummy configure event when resizing while fixed
When a fixed size is active (e.g. the window is maximized),
gtk_window_resize() shouldn't take immediate effect, so the request was
dropped. This made GTK unhappy if this happened, it will freeze updating
the window until it received the new size it demanded.

Handle this by being nice and emitting a dummy GDK_CONFIGURE event with
the old size where we previously ignored it. It won't resize the window
immediately, so it shouldn't have a visible effect, and the size GTK
requested is still saved away for when the window is unmaximized, but
emitting the event will make GTK receive the event it expects.

We still drop the request on the floor, e.g. if we still haven't seen
the initial configuration, just as we do when actually doing the resize.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2907
2020-09-07 17:57:32 +02:00
Julien Ropé
f26c026aaf Fix resource leak in gdk_display_close() under Wayland
When using the gdk_display_close(), the handle to the Wayland compositor was not released.
This could cause the consumption of all available handles, preventing other processes from accessing the display.

Fixing this by calling wl_display_disconnect() when releasing the GdkWaylandDisplay object.

Signed-off-by: Julien Ropé <jrope@redhat.com>
2020-08-31 14:01:38 +02:00
Matthias Clasen
3795d0ad8c Merge branch 'wip/exalm/hotspot-fix-324' into 'gtk-3-24'
wayland: Fix dnd hotspot movement

See merge request GNOME/gtk!2491
2020-08-26 23:48:48 +00:00
Alexander Mikhaylenko
c67e3f37da wayland: Fix dnd hotspot movement
_gdk_wayland_window_offset_next_wl_buffer() moves the window relatively to
its current position, pass it a delta instead of new position.
2020-08-27 04:02:24 +05:00
Carlos Garnacho
b1bbb37154 gdk/wayland: Use double-click/drag-threshold settings from g-d-s
Handle both these settings, and the older settings-daemon ones for
backwards compatibility. The keys are already checked for existence
in the schema, so it will just use the existing ones.
2020-08-27 00:30:51 +02:00
Carlos Garnacho
e6209de962 gdk/wayland: Look for font settings in gsettings-desktop-schemas
Prefer this location, but also look for the old location in
settings-daemon for backwards compatibility. This applies to both
direct settings lookups and via the settings portal.
2020-08-27 00:30:38 +02:00
Christian Rauch
8e99b3f079 wayland: prefer a manually requested size over the configure hint
When a window receives a resize request, it might ignore this new size and
use the compositor's size hints instead to restore to floating mode.

This commit changes that behaviour in that a window will always prefer
the manually resized dimensions over the compositor's hint.
2020-07-15 16:14:25 +01:00
Caolán McNamara
2b74662b2b gtk#767 add a way to change the application_id of a toplevel wayland GdkSurface
so LibreOffice can reuse toplevels and get the right task icons

references;
 https://gitlab.gnome.org/GNOME/gtk/-/issues/767
 https://lists.freedesktop.org/archives/wayland-devel/2019-July/040704.html
 e0d6ad1d5e
 https://bugs.documentfoundation.org/show_bug.cgi?id=125934
 https://bugzilla.redhat.com/show_bug.cgi?id=1334915
 https://bugreports.qt.io/browse/QTBUG-77182
2020-07-07 21:14:21 +01:00
Sebastian Keller
9459be11a9 wayland: Signal gtk-shell surface destruction to the server
This adds a "release" destructor for the gtk_surface1 interface which
signals to the server that a surface has been destroyed on the client
side, which the current "destroy" does not do.

Ideally the protocol would have specified a destroy request marked as
destructor to handle this automatically, however this is no longer
possible due to the destroy method being implicitly generated in the
absence of an explicit request in the protocol. Adding a destroy request
marked as destructor now would generate a new destroy method that
unconditionally would send the request to the server, which would break
clients running on servers not supporting that request.
2020-06-11 11:38:21 +02:00
Sebastian Keller
7998c53396 wayland: Remove unused fribidi include
The included fribidi header is not used in gdkkeys-wayland.c and already
included in gdk.c which causes linker issues due to the header defining
a global variable.
2020-06-04 21:08:20 +02:00
Carlos Garnacho
948782b7e5 gdk/wayland: Handle disorderly tablet/pad disconnects
If the tablet gets removed/freed while there are pad events in flight,
we leave a dangling pointer from the pad to the tablet, which may
lead to invalid reads/writes when handling the pad event(s).

Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2748
2020-05-15 18:47:14 +02:00
Alberto Fanjul
1e2d72144a Prevent crashes on gdk wayland implementation using offscreen windows 2020-04-28 15:14:53 +02:00
Jonas Ådahl
cf060b4c7d wayland: Move warning about transient-less temporaries to map()
We shouldn't warn in a funtion that seemingly only checks how something
eventually should be mapped.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2589
2020-04-08 11:43:49 +02:00
Jonas Ådahl
c5d9c8be2b wayland: Always store unconfigured size
This means it'll always be as up to date GdkWindow::width/height. We
still skip the resize for non-configured windows though, to avoid
mapping with the wrong size.

The commit f06ee688fe also accidentally
removed the unconfigured size setting completely, so this essentially
adds it back, but always sets it.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2582
2020-04-07 09:00:26 +02:00
Jonas Ådahl
f06ee688fe wayland: Don't inhibit premature resize for popups
So now we essentially only inhibit the premature resize for toplevel
windows, where it is most crucial. For popups, this didn't work for two
reasons: we relied on the owner of the popup (application) to resize
according to the configured size. For custom popup operators like
Epiphany and LibreOffice, this didn't work out well, since they simply
didn't.

Making gdk do it for them in case they didn't themself did make the
popups show up properly, but there were still some weirdness in
LibreOffice where tooltips didn't still didn't get the right size. So,
even though the size set by application may be different from the one
later configured by the display server, let the applications have their
way and see their resize result immediately. It's fairly likely to be
what they eventually get anyway.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2583
2020-04-06 22:02:02 +02:00
Jonas Ådahl
92aa63c203 wayland: Set unconfigured size on impl construction
Who knows who might use this for something, so lets make the
unconfigured size slightly more predictable. This doesn't fix anything
known to be broken though.
2020-04-06 22:01:12 +02:00
Simon McVittie
46165b52e5 wayland: Guard against nonsense sizes being configured
With the fixes from !1638, it shouldn't be possible for this to happen
any more. However, non-positive sizes make no sense regardless, so if
this does somehow happen, let's make sure *something* reasonable happens.

The practical result of this assertion being hit is that we emit a
critical warning and then behave the same as if !1634 had been merged,
which is known to solve the issue for the submitter.

Signed-off-by: Simon McVittie <smcv@debian.org>
2020-04-06 13:33:09 +01:00
Jonas Ådahl
814d1e7f06 wayland: Store unconfigured size without margin
We get the unconfigured size request either with or without the shadow
margin already configured, so to get some consistency with the 'saved
size', cut away any potential shadow margin from the size before
storing.

Then when using, add it back, so we always create a configure event with
the correct size.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2576
2020-04-06 12:13:01 +02:00
Jonas Ådahl
2e5f344e3c wayland: Always update unconfigured size
If the window size didn't change, we should still update the
unconfigured size as the window size might not be up to date.
2020-04-06 12:05:58 +02:00
Jonas Ådahl
a4984cfd40 wayland: Use helpers to add/remove margins from sizes 2020-04-06 12:05:13 +02:00
William Wold
5a52af20cb Do not require an initial configure for DnD windows
Fixes #2075
2020-04-05 07:11:45 -04:00
William Wold
12fc9a45ef Do not require an initial configure for custom Wayland surfaces
There is no way for custom Wayland surfaces to get configure events, so an
initial configure event should not be required to resize a custom surface.

Fixes #2578.
2020-04-05 05:28:55 -04:00
Jonas Ådahl
749d940887 wayland: Don't postpone resizes for subsurfaces
Subsurfaces won't ever receive a configure event.

Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2570
2020-04-03 18:04:44 +02:00
Jan Alexander Steffens (heftig)
c27cb675b7
gdk/wayland: Clear modifiers when we lose keyboard focus
When we `Alt+Tab` away from a GTK application, it loses keyboard focus.
If we don't clear the modifiers, events from other devices that we
receive while unfocused will assume `Alt` is still pressed. This results
in e.g. Firefox navigating through the history instead of scrolling the
page when using the mouse wheel on it.

We don't get any information about modifiers while we are missing
keyboard focus, so assuming no modifiers are active is the best we can
do.

The shell sends us a modifier update immediately before we regain
keyboard focus, so the state shouldn't get out of sync.

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2112
2020-04-02 20:45:55 +02:00
Jonas Ådahl
3b91c20eac wayland: Add margin to saved size when restoring size
We're normally going from a fixed size to a floating state when we're
using the saved size, meaning we're practically always going towards a
state where the shadow margin will non-empty. However, if we don't
include any margin when creating a new configure request, we'll end up
resizing to a slightly smaller size as gtk will cut off the margin from
the configure request when changing the window widget size.

This wasn't visible when e.g. going from maximized to floating, as we'd
add the shadow margin at a later point, which would effectively "grow"
the widnow size, but when we're going from tiled to floating, we both
start and end with a non-empty shadow margin, meaning we'd shrink ever
so slightly every time going between tiled and floating.
2020-04-02 18:10:03 +02:00
Jonas Ådahl
50aa947e51 wayland: Treat being tiled as maximized when saving size
We should never save a size when we're tiled, just as we shouldn't when
we're maximized. This fixes returning to the correct floating size after
having been tiled or maximized.
2020-04-02 18:10:03 +02:00