This will sometimes mean a frame is skipped if a resize was requested
during the update phase of the frame dispatch. Not doing so can cause
trying to allocate a window smaller than the minimum size of the widget.
If compute_size() returns TRUE, the layout will not be propagated to
GTK. This will be used by the X11 backend to queue asynchronous resizes
that shouldn't yet allocate in GTK.
Not doing this means the next time the same surface is shown, if the
shadow size wasn't changed, it wouldn't be sent to the compositor, which
then would result in compositor deriving its own window geometry which
would include the shadow margin.
This fixes an issue where the file chooser dialog would grow each time
it opened.
The allocation of popups are part dependent of the allocation of the
root, which means the root must still be allocated when updates are
frozen, otherwise we'll try to allocate non-laid out popups.
This fixes an issue where the focus of the window continuously received
fake motion events even when a popover was open, making input events end
up behind the popover.
It also adds a comment describing why motion events are requested. Note
that popovers won't work with this, and it's possible both in the past
and now that sporadic missplaced motion events will appear, e.g. when a
window changes allocation but a popover is open.
This removes the GDK_CONFIGURE event and all related functions and data
types; it includes untested changes to the MacOSX, Win32 and Broadway
backends.
While the workaround hides majority of the issue there are still two big downsides:
- shadow does eat from the widget dimensions so alignment is broken
- situations like popover going upwards on screen edge break completely
The appropriate action is to revert these theme duct tape solutions to make room
for a proper fix.
This reverts commit b3dba1dca6.
Issue https://gitlab.gnome.org/GNOME/gtk/-/issues/1987
This removes the gdk_surface_set_shadow_width() function and related
vfuncs. The point here is that the shadow width and surface size can now
be communicated to GDK atomically, meaning it's possible to avoid
intermediate stages where the surface size includes the shadow, but
without the shadow width set, or the other way around.
This changes allocation of the widget trees to happen as a side effect
to the GdkSurface::layout signal, which first passes the GtkNative
instance where it is then forwarded to the implementations of the
GtkNative interface.
The implementations of GtkNative are the ones doing the actual
gtk_widget_allocate(), and they do so in their GtkNativeClass::layout
function.
The size should correspond what gtk_widget_measure() does, and it
measures what's within the window excluding the shadow; so make this
helper function correspond to this.
GTK4 doesn't support arbitrary constraints when resizing a window (e.g.
steps, or aspect ratio), so we don't need to care about the result from
compute-size when doing interactive resizing.
This follows the trail of the Wayland backend in that GdkSurface changes
happen during the layout phase, and that a GDK_CONFIGURE no longer being
used to communicate the size changes of a surface; this now also uses
the layout signal on the GdkSurface.
If a surface scheduled a relayout, got frozen, and a layout phase
happened, then got unfrozen, it wouldn't see it's layout being
requested; avoid this race by remembering the pending phases until they
actually happened.
Reading the comment, it seems to be related being a window manager
decoration utility; this is not something GTK4 aims to handle, just drop
support for this.
Showing before the child would result in bogus
gdk_drag_surface_present() with an "empty" (1x1) size. This can easily
be avoided by postponing showing until there is anything to show.
By moving popup layout emission to the layout phase, the current
GdkPopup::poup-layout-changed signal has no value on its own as it'd be
ignored by GtkPopover.
Make the Wayland backend communicate the popup layout changes via the
common signal; but leave the rest intact until other backends catch up.
