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.
The `name` and `description` events were added to `xdg-output` protocol
in version 2 which is part of wayland-protocols 1.14.
In xdg-output-v1 version 3, the `xdg-output.done` event was deprecated
and the `xdg-output.description` event was made mutable, but that
doesn't change the actual events so we do not actually need to require
that version of xdg-output from wayland-protocols 1.18.
Update the wayland-protocols requirement to the bare minimum version,
which is 1.14.
https://gitlab.gnome.org/GNOME/gtk/issues/2057
This commit fixes the values passed to darwin_versions. When
transitioning from an autotools build, one should always use:
[lt_current + 1, '@0@.@1@.0'.format(lt_current + 1, lt_revision)]
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
Commits a04fef4 and cc7f9c4 inadvertedly broke Visual Studio builds as
it caused the following to show up when configuring:
gdk\meson.build:281:0: ERROR: Invalid Shared library version "vs9.2404.4". Must be of the form X.Y.Z where all three are numbers. Y and Z are optional.
Since we do not set a library version that mingles with the minor and
micro versions, along with libtool current for any Visual Studio builds,
just set those versions as 3 on Visual Studio builds, and things should
work the way they did before.
Make it a yes/no/auto combo. "yes" means all modules are built into libgtk,
"no" that none are and "auto" uses the platform defaults, yes on win32,
no otherwise.
If we need more we can always extend it later.
This makes the DLL names match those that are produced by the Visual
Studio projects by default.
This, currently, however, names the .lib files same as the ones that
are produced for other platforms (i.e. <libname>-3.lib). This is
actually not that bad as one can just copy those .lib's into
<libname>-3.0.lib when needed and the binaries that link to those .lib's
ultimately link to the same DLLs, so this should not harm binary
compatibility.
It may be so that Cairo is not found using pkg-config files, so we
cannot just use .name() on the Cairo deps directly.
Since we already have a similar mechanism for generating the GDK .pc
files, re-use and share that mechanism.
