This reverts commit 749a58ab26.
This maintains feature parity with the autotools build. To achieve the
equivalent of --with-included-immodules=wayland,
-Dbuiltin_immodules=wayland,waylandgtk can be used instead.
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.
fmin() is a function that is introduced with C99/C++11, so check for the
presence of it and provide a simple implementation for it if it does not
exist.
Also update the config.h.win32.in template accordingly, since this
function is provided on Visual Studio 2013 or later.
epoxy_dep cannot be used in a configure time check when it comes from a
subproject. Use variables set in pc file instead.
This requires https://github.com/anholt/libepoxy/pull/231.
When a plug is embedded in a socket, we need to also plug the at-spi
tree, so that screen readers can find the at-spi content of the plugged
widgets.
This change does this plugging automatically: on the plug widget, an
additional _XEMBED_AT_SPI_PATH property is set to provide the at-spi path
(just like we have _XEMBED_INFO for other X11 information), and when
embedding it, the socket reads it, and makes it as its only child.
Since GtkPlugAccessible can not inherit both from AtkPlug (a child of
AtkObject) and from GtkContainerAccessible (a child of AtkObject), we
actually make GtkPlugAccessible a child of an AtkPlug, and that's what
will be embedded (in at-spi terms) into an AtkSocket.
Similarly, GtkSocketAccessible can not inherit both from AtkSocket and
GtkContainerAccessible, so we make it a parent of the AtkSocket that
embeds the AtkPlug.
This change depends on atk 2.35.1 which implements the at-spi technical
details.
This separates out atk-bridge-2.0 dependency, which is not part of atk,
but of at-spi2-atk.
This implementation is based on gtk_text_view_scroll_to_iter() and
thus shares its limitations for the sake of simplicity.
A single offset is opportunistically picked to build the iterator
needed for gtk_text_view_scroll_to_iter(). That means that substrings
spanning over multiple lines or larger than the current window might
not be displayed optimally after scrolling.
Partially closes#1625, the toPoint() variant has been discarded.
Additionally to gtk_primary_selection, the gtk-private predecessor,
support the upstream unstable protocol.
This allows the primary selection to work on Kwin and potentially
other compositors, as well as dropping the private version eventually.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2591
Path concatenation is much nicer than the unwieldy format method.
Since paths returned by get_option are relative to prefix, they will be joined as before.
As a bonus, this fixes weird platforms like NixOS that actually pass absolute includedir under a different prefix.
This avoids the build from erroring out on C4819 (Unicode handling issue in
Visual Studio compiler), notably when running on Chinese, Japanese and
Korean locales.
On Visual Studio, Cairo could have been found manually by looking for the .lib
files, and the previous update to fix this was incorrect, as it added the
libraries to the required packages instead of the required libraries. This
fixes this mishap
The Quartz Window Manager adds to the Windows menu all NSWindows with
titles. Since we assign a default title to all windows that produced a
rather cluttered Windows menu containing among other things dialogs.
Setting aside that dialogs don't belong in the Windows menu, if
a dialog was hidden for reuse instead of destroyed it would persist in
the Windows menu and if clicked there would show, but because it wasn't
running wouldn't respond to events and so couldn't be hidden again and
would remain on top of its parent window.
Ref: https://bugs.gnucash.org/show_bug.cgi?id=797807
Since we're shipping both Meson and Autotools build systems for GTK3,
and both of them have a version field, it's bound to happen that the
GTK version defined in either build systems will go out of sync.
Let's add a check in both builds so that something will fail before
doing a release in case the versions do not match.
In addition to the traditional library directory lib and the 64-bit
multilib directory lib64, this will cover Debian-style multiarch
(lib/x86_64-linux-gnu etc.), Arch Linux 32-bit (lib32), x32 and
various others.
Signed-off-by: Simon McVittie <smcv@debian.org>
In a4fe15d9f0, the wayland-scanner command was changed to use
`private-code`, which was first introduced in wayland-1.14.91. This
was synced from master commit a2a99d27c9, which *did* include a
corresponding wayland version requirement bump, but it appears that
this was lost in the sync.
