This makes the desired behaviour explicit, and matches the behaviour
seen with Meson, where "external : false" is the default.
Before GNOME/glib!1468, not passing --internal to the resource compiler
meant "no special export attribute, do what you would normally do",
so these symbols were not exported due to our global use of
-fvisibility=hidden.
However, since GNOME/glib!1468, not passing --internal to the resource
compiler results in the symbols being decorated with G_MODULE_EXPORT,
which overrides -fvisibility=hidden. This was necessary because Windows
DLLs normally behave a bit like the equivalent of ELF libraries with
-fvisibility=hidden.
Signed-off-by: Simon McVittie <smcv@debian.org>
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/2919
Add --enable-tracker3 option (off by default, like in meson) and
hook the tracker3 search engine to build. Also, make sure it's part
of dist.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2912
Input devices such as stylus pens have additional axes besides (x,y)
coordinates. In order for these devices to work properly, their additional
axes need to be mimicked from the physical device to the associated
virtual pointer when they become active.
If GLES support is enabled on Windows, force GLES mode if we are running
on a ARM64 version of Windows (i.e. Windows 10 for ARM).
This is required as ARM64 versions of Windows only provide a software
implementation of OpenGL 1.1/1.2, which is not enough for our purposes.
Thus, we could make instead use the GLES support provided via Google's
libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we
can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows.
Note that eventually we could update the libepoxy build files for Windows
to not check nor enable WGL when building for ARM64 Windows, as the WGL
items do not work, although they do build.
For some reason modules/input adds the C code that is generated by
wayland-scanner to EXTRA_DIST. This results in a race where depending
on the timestamps of the tarball and the timestamp of the system
wayland-protocols either the generated source in the tarball or a
regenerated source will be used.
This doesn't actually impact the code generated, but it does break
reproducible builds as the list of source files changes.
When making changes above the current visible region, we might need to
invalidate the pixelcache as the Y positions will no longer match. This
usually is not needed because changes are made interactively and are made
onscreen.
Other cases, though, can include an application changing the first line
of the buffer automatically. We lose the ability to pixelcache well in
this scenario, but that is unlikely an issue since rapid Y geometry resize
or scrolling is less likely to be occuring. For situations where this is
an issue, you can avoid removing the \n from the buffer so line heights
are uneffected.
Fixes#2882
The pkg-config variables have been added in GLib 2.62.0. Let's fallback
to default names for these tools in such case (`pkg-config` still
returns a 0 return value, but with empty output for absent variables).
Some distributions are renaming Glib/GIO utilities for multi-arch
reasons so pkg-config variables have been added to find the correct name
of a tool. GTK+ should use these variables instead of searching in PATH.
See glib#1796.
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
