Basically, I was building some packages on Guix. I figured out that
wayland-protocols was listed among propagated-inputs for gtk+ package
(gtk-3-24). propagated-inputs holds a list of runtime dependencies,
that should be available to any other package that depends on gtk+.
While discussing we clarified that wayland-protocols is not runtime
dependency. So I moved it to native-inputs of gtk+ package, which
means that, this dependency will be available only to gtk+ package and
only at build time. Once moved, building of other applications that
depening on gtk+ started to fail.
Investigation showed that, all .pc (pkg-config) files prepared by gtk+
package, was including:
Requires.private: ... wayland-protocols ...
Since it becomes requirement, other applications was failing with
missing dependency wayland-protocols of dependency gtk+, for instance:
-- Checking for module 'gtk+-3.0'
-- Package 'wayland-protocols', required by 'gdk-3.0', not found
While actually wayland-protocols is not even a build time dependency
of application that depends on gtk+. Advertisement of such
requirement, is a bit misleading, because one does not need it at
runtime, especially applications based on gtk.
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 5044031b53)
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 53df32e6cf)
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.
