When the compose file is a symbolic link, take the link itself's
modification time into account (in addition to its target's) in
determining whether to invalidate the compose cache.
This is useful e.g. on NixOS systems where the compose file might point
to a store path with an irrelevant modification time, and we want the
cache to expire when the symlink itself changes.
(cherry picked from commit 22f5236943)
Ping/pong serials are not meant to be interpreted as user input serials
(e.g. those given back later to the compositor on grabs). As a matter
of fact, Mutter uses a different count (i.e. timestamps) in these, so
using these serials may confuse the compositor into denying certain
operations like DnD.
In macOS-12.sdk CGContextConverSizeToDeviceSpace returns a negative
height and passing that to CGContextScaleCTM in turn causes the cairo
surface to draw outside the window where it can't be seen. Passing the
absolute values of the scale factors fixes the display on macOS 12 without
affecting earlier macOS versions.
Like the Visual Studio 2012+ projects, copy the Visual Studio 2010
projects and replace the items in there as needed, so that we can
obtain Visual Studio 2022 project files, since they are all in the
MSBuild format.
The rc.exe that comes with the Windows 11 SDK does not allow one to include
winuser.h directly in the .rc scripts, so make sure that we do not try to
generate the final gtk.rc with it, but instead include windows.h with
WIN32_LEAN_AND_MEAN defined.
The resource compiler in the Windows 11 SDK does not allow one to include
winuser.h directly in resource scripts (.rc) with a rather cryptic error
message, so fix generating the .rc file to embed the UAC manifest by including
windows.h with WIN32_LEAN_AND_MEAN instead.
Broadway is the only GTK+ backend that throws an error on stderr for a
"display server" connection failure.
This causes problems when gtk_init_check() is used and unexpected error
output is generated such as with hotdoc, which fails when generating a
GTK plugin's documentation instead of overlooking the issue.
"Unable to init server: Could not connect: Connection refused"
It is necessary to signal the search engine that we are finished and
that we found something for it to reliably show the results. It would
sometimes work anyway since it is sufficient if any backend signals
completion. However if GtkSearchEngineModel was the only backend
returning results then things would break.
MinGW-w64 CRT provides no 'hid.lib' file. Instead, it has 'libhid.a'
which can be linked with '-lhid' linker argument.
Also, we have to declare the '_LIBADD' variable and add 'LDADDS' to it,
or 'LDADDS' won't do anything for the build.
Note that gdk_monitor_get_geometry () returns DPI-scaled values,
while the screen offset should be unscaled, as scales are properties
of indivdual monitors.
An arithmetic operation involving a signed and an unsigned operand
of the same rank will have both operands converted to *unsigned*.
That's an issue if the signed operand actually has a negative value.
That was causing issues with the handling of monitor geometries that
had negative x / y positions.
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.
