This function was not doing the right thing.
Once we are doing the right thing and not compare
shadows as unequal, some reftests that inhibit
snapshots for a few frames now hang forever, since
we are no more redrawing unnecessarily. Fix that
with an explicit queue_draw.
Sometimes the size will exceed the minimum bounds. For example crazy
applications like the widget factory that contains the world, or when a
user interactively resizes a window to be larger than the monitor the
window is on is.
The former is questionable, but the latter is not, and from here we
can't really see the difference, so just stop complaining.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3035
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.
Setting can-focus to FALSE on a widget is supposed
to prevent focus from entering the entire subtree.
So when we grab focus directly to a widget, we need
to check the can-focus flag not just of the widget
itself, but all its ancestors.
Fixes: #3610
We only realize the ATContext on the top level, which will create an
GtkAtSpiRoot object and the corresponding GtkAtSpiCache object. Whenever
an AT connects to the accessibility bus, and asks for the various
objects, all the ATContext will be realized on demand.
As the program executable name has 'update' in its filename,
gtk4-update-icon-cache.exe is considered to be an installer program on 32-bit
Windows [1], which will cause the program to fail to run unless it is running
with elevated privileges (i.e. UAC).
Avoid this situation by embedding a manifest file into the final executable
that tells Windows that this is not a program that requires elevation.
Fixes issue #3632.
[1]: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc709628(v=ws.10)?redirectedfrom=MSDN,
under section "Installer Detection Technology"
