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.
Commit 68188fc948 introduces a workaround for clients that try to
change the size of a popup after it is created, but inadvertently
introduces an infinite loop of surface creation when the popup enters
two or more wl_outputs with different scales on creation.
This commit checks if the size actually changed before applying the
workaround and avoids the loop.
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.
...if GLES (libANGLE) support was enabled in the build. This way, we can
check whether the GL driver is capable enough to support the OpenGL
features that we use in GTK. If the driver is not capable enough, and
GLES support is enabled, we can try to create the GdkGLContext again as a
GLES context.
Group the WGL-specific code and GLES-specific code together, so that we
can reduce the number of #ifdef ... in the code, to make the code more
readable and easily maintained. This will pave the way to add a
fallback mode to use libANGLE (OpenGL/ES) in case the Desktop OpenGL
support is inadequte, if OpenGL/ES support is enabled in the build.
This is somewhat based on the updates that were done in GTK master, so
we are using one subclass for WGL-based GdkGLContexts, and another for
GLES-based GdkGLContexts.
Also remove the underscores in many of the functions in
gdkglcontext-win32.*.
Clean up the code a bit as a result.
When a popup is remapped, if the GdkWindow::x/y position is negative,
some best-effort hueristics used to ignore internal X11-style hackery
windows incorrectly scooped up remapped popup windows.
Avoid these hueristics by resetting the x and y fields of GdkWindow to 0
whe hiding a popup. It'll then appear as if it was newly initialized,
and escape the mentioned hueristics.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4071
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)
