Gdk doesn't know the scale of output globals it didn't bind. This
keeps them from entering the output list and triggering erroneous
changes in surface scales.
gdkinternal-quartz.h isn't installed but the headers that included
it are, which which would cause the build to fail if an external
project included one of them.
Also changed the includes in gdkinteral-quartz.h to local for
faster loading.
Avoid diagnostics for gcc-11 false positive out of bounds accesses
See merge request GNOME/gtk!3064
(cherry picked from commit 5044031b53988627c2937c6b5f8919a37e18f21f)
c514c41d Avoid diagnostics for gcc-11 false positive out of bounds accesses
While gtk-doc doesn't care, this isn't really valid Markdown as the
GtkBuilder custom XML tags will be considered valid markup and embedded
as they are, breaking the HTML output.
Like the recent updates in GTK4, the HWND that we use to obtain the HDC
that we need for OpenGL/GLES operations should really be tied to
GdkWindow, not GdkDisplay, as that is where the Win32 HWND where we
originate from is located, so stop storing the GL HWND in
GdkWin32Display, but just grab them from the GdkWindow that is bound to
the GdkGLContext.
We are more conservative about freeing up GL resources in GTK3, so we
will continue to call ReleaseDC() as we did before.
When a new sequence is added to a GtkGesture, its state is looked
in other gestures in the same group, and made to match in this
gesture. This however happened a bit too early, before the
gesture touchpoint was fully set up. As this may result in signal
emission and whatnot, it's a good idea to make it happen with a
fully set up touchpoint.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3946
(Cherry-picked from commit 53df32e6cf1e2a7cbec8dd8d3b3acd4ddae2b9bf)
Set all settings to their default values, so we
are less dependent on the environment to be set
up just right. In particular, this fixes animations
being disabled when we happen to run in a vm.
