When we are not doing baseline alignment, don't pass
a baseline to the allocated widget. This helps because
a number of widgets (GtkLabel, GtkEntry, etc) always
position their text on the given baseline.
Since we show them in GNOME shell, show them here too.
The comment that says "only show these in the a11y
theme" was still there, but we were always hiding them.
The Expose events following a ConfigureNotify may arrive at
a time that we did not resize the surface yet, making these
expose events a no-op. Even though gsk/gtk take care of the
window content itself, this might lead to unrendered portions
of the window shadow.
This may be seen with GSK_RENDERER=cairo and GDK_BACKEND=x11,
attempting to tile a window (e.g. gtk4-demo) left or right.
The window will show black rectangles or other artifacts in
the window shadow areas that correspond to the newly painted
portions (as the window needs to expand vertically).
In order to fix this with a similar behavior to Wayland,
consider ourselves the whole surface invalidated after resize,
in order to ensure everything is painted from scratch.
... when it is available.
Also introduce the new function gdk_rectangle_transform_affine(), which
looks like overkill for this purpose, but I'm about to use it elsewhere.
Drop the section that talked about main and how to update
local checkouts - its been 2 years, people should have gotten
around to it by now. Add some general git hints instead.
There's no need for EGL to do any timing, we do it in GTK already.
This fixes hangs in Mesa when we hide a surface after a SwapBuffers()
but before the frame callback arrives.
If we then reshow the surface and immediately render to it, Mesa would
still have a frame callback from before the hiding and forever poll()
waiting for the compositor to send the callback.
Fixes#5761
donʼt mention its renamed successor either, as that has its own section
later. We could have another sentence paragraph like ‘In the case of
GtkBox, the pack methods have been renamed to X and lost the trailing
arguments Y’, but that wonʼt help people prepare still on GTK3, which is
the point in the affected section… so just remove the misleading relic.
When adjusting allocations, treat BASELINE more like CENTER
than like FILL. The results are better, in particular for
controls like entries or switches, which we never want to
scale up vertically, but still want to align to the baseline.
A grid layout lets us get the baseline right in
vertical orientation, by setting a baseline row.
It would be nice if the box layout supported this
as well, but currently it doesn't, and adding that
feature isn't trivial.
