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
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
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.
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
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
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.
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>
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
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.
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.
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.
If a window is configured with a fixed size (it's tiled, maximized, or
fullscreen), ignore any resize call that doesn't respect this. The set
size will instead be saved, when appropriate, so that the new size is
used when e.g. unmaximizing.
This makes it possible to call 'gtk_window_resize()' while the window is
maximized, without the window actually changing size until it's
unmaximized. Changing size to a non-maximized size is a violation of the
xdg-shell protocol.
An application may want to set a fallback size of a window while still
mapping maximized. This is done by calling gtk_window_resize() before
gtk_window_maximize() and before gtk_window_show(). When the window is
mapped, it should have a maximized size, and if it eventually is
unmaximized, it should fall back to the size from the earlier
gtk_window_resize() call.
What happens before this commit is that the initial window size ends up
respecting the first gtk_window_resize() dimensions, and not the window
dimension configured by the Wayland display server (i.e. maximized
dimensions).
Fix this by postponing any configure events until we received our
configuration from the display server. If we got one with a fixed size
(e.g. we're maximized, tiled etc), we use that, otherwise we look at the
one that was previously configured by gtk which corresponds to the
"preferred" size when not being maximized.
This fixes Firefox being started in a maximized state when using the
Wayland backend.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2538
On Wayland, opening and closing a `GdkDisplay` generates a coupe of
warnings at runtime:
```
GLib-GObject-WARNING **:
invalid cast from 'GdkWindowImplWayland' to 'GdkWindow'
GLib-GObject-WARNING **:
invalid cast from 'GdkWaylandWindow' to 'GdkWindowImplWayland'
```
This is from `gdk_window_impl_wayland_finalize()` which tries to cast
the given GObject to a `GdkWindow` while it's a `GdkWindowImplWayland`.
Use the correct type casting of objects to avoid the warnings.
If a client issues a `move_resize()` request while the window is
maximized or fullscreen, update the saved size for when it will be
unmaximized/unfullscreened
Related: https://gitlab.gnome.org/GNOME/gtk/issues/1044
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
The event received in `gdk_wayland_window_show_window_menu()` can
come from widgets with a GdkWindow. In those cases the coordinates
are relative to the widget, not the root window.
This results in a misplaced window menu.
Properly calculate the coordinates by iterating to the toplevel
window as suggested by Carlos Garnacho.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/684
This uses the gtk_surface1.request_focus request added in gtk-shell v3,
the given startup ID may be used by the compositor in order to determine
when was the request started, and whether user input happened in between.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/624
If the size was constrained by the xdg_positioner mechanisms, we handle
the resize by resizing the popup window. What we shouldn't do is
hide/show the popup window so avoid that.
Suggested by Garnacho. Hopefully fixes#1349.
Note: I'm riskily committing this via web UI not because I'm lazy
(though I am :) but because I'm seeing a weird host key when I try to
push or pull from GitLab.
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
The enum is duplicated in the spec for the manager and the decoration
object. We should be using the right ones. In practice they have the
same value, so this bug didn't cause any issues.
The wl_surface is destroyed and recreated when the window is
mapped/unmapped. As we have a new wl_surface we need to create a new
server_decoration object for that surface.
According to the spec compositors were to assume surfaces are CSD until
told otherwise. This means we need to send
org_kde_kwin_server_decoration_request_mode in both cases.
This fixes libreoffice under kwin, which would remove it's own headers
as per the manager's request but not inform kwin leaving it in the even
more broken state of having none.
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
The stable xdg_shell port (5c8bb51a) introduced an error in
gdk_wayland_window_set_geometry_hints which would set the minimum size
to the maximum size, if provided.
This resulted in various wxWidgets apps (FileZilla, Audacity, Veracrypt)
crashing because they attempted to allocate a ginormous surface.
Fixes#157.
If a window is unmapped by the client while gdk is processing updates,
(for example Firefox un-mapping its window on Expose events), the
windowing backend resources might be lost (for example with Wayland)
which can cause a crash in end_paint().
Make sure we drop the cairo surfaces as well when hiding the surface,
that will avoid the crash in gdk_window_impl_wayland_end_paint() when
trying to attach the staging cairo surface to a released wl_surface,
these will be recreated when needed when the surface becomes visible
again and there is no need to keep such buffers around for a surface
which is not visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=793062
This commit adds support the stable version of the xdg-shell protocol.
Support for the last version of the unstable series is left intact, but
will not receive new features.
The stable version is prioritized above the older version.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
In order to map a window with the correct initial parent-child
relationship when a modal dialog is set up to be a child of an imported
foreign window, the relationship must be set up before the window is
mapped.
In order to do this, if a window is not yet mapped, postpone the
relationship setup until when the window is eventually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=791062
This state flag is used in several places in GTK+, for example to
ignore RESIZE_INC hints if tiled. Setting it is also necessary for
backwards compatibility with applications that changed their behaviour
when tiled, such as GNOME Terminal and its MATE fork.
Signed-off-by: Simon McVittie <smcv@debian.org>
https://bugzilla.gnome.org/show_bug.cgi?id=789357
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
Under Wayland, an xdg_surface.configure with size 0x0 means it's up to
the client to set its size.
When transitioning from maximized state to un-maximized, the Wayland
compositor will send such an 0x0 configure so that the client can
restore its original size.
However, the original size was already constrained, so re-applying
size constrains can lead to a smaller size when using size increments.
Avoid this caveat by not applying size constrains when we are restoring
the original size.
https://bugzilla.gnome.org/show_bug.cgi?id=777072
