We only called xdg_toplevel.(un)set_maximize() if the toplevel layout
changed, but this misses the case when the compositor had changed the
maximized state. Change it to call the xdg_toplevel request if either
the local layout changed, or if the layout differs from the current
state.
This fixes an issue where one couldn't unmaximize a window by double
clicking the titlebar that, had previously been maximized e.g. using a
keyboard binding.
Do the same for fullscreen.
This makes it possible to set 'maximized' to true in .ui files, and the
window will show up maximized.
gtk_window_is_maximized() will return the intended maximized state until
actually mapped, it will then show the actual maximized state. The same
applies to reading the property.
This commit changes the behavior of window size computation and the
default size properties to:
* The default-width and default-height properties are updated to the
current window size unless the size is fixed by e.g. being maxmized,
tiled etc.
* The compute-size semantics are to just pick the default size, or if
not adequate, use the measured size, and consequently update the
default size, unless unresizable.
* gtk_window_get_size() is removed, what's more likely relevant is the
gtk_window_get_default_size() which will now contain more sensible
values.
Various places that used gtk_window_get_size() were updated to use
gtk_window_get_default_size() to remember and restore previous sizes.
This also changes the default value of 'default-width' and
'default-height' from -1 to 0. The gtk builder simplify tool is taught
how to omit when the default size is set to both -1 and 0.
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.
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.
