Sprinkle various g_assert() around the code where gcc cannot figure out
on its own that a variable is not NULL and too much refactoring would be
needed to make it do that.
Also fix usage of g_assert_nonnull(x) to use g_assert(x) because the
first is not marked as G_GNUC_NORETURN because of course GTester
supports not aborting on aborts.
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.
Also apply -D_USE_MATH_DEFINES, -FImsvc_recommended_pragmas.h and -utf-8 to
the C++ compiler options as well.
Copy just enough of libwayland-cursor to make our own
loading. This lets us drop the dependency on libwayland-cursor,
and changes the startup cost for cursor theme loading
from 25ms to 0.1ms.
At the same time, simplify the handling of scaled cursors -
instead of creating an array of theme objects, just make a
single theme object provide all scaled cursor sizes.
sincosf() is really a GCC-specific function that may more may not be
supported on non-GCC compilers, so we want to check for it, otherwise we
use a fallback implementation, not unlike the one in
demos/gtk-demo/gtkgears.c.
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
Use cairo-script-interpreter to parse the scripts that generate cairo
nodes.
This requires libcairoscriptinterpreter.so to work properly, but if
it isn't found we disable this (unimportant for normal functioning)
code and just emits a parser warning.
The testsuite requires it however or it will fail.
A new test is included that tests all of this.
This uses the new sysprof-3 ABI to implement the capture writer. It also
uses the statically linked libsysprof-capture-3.a that is provided with
Sysprof for the capture writing to ensure that we do not leak any symbols
nor depend on any additional libraries.
The GTK_TRACE_FD can be used to pass a FD for tracing into Gtk. Sysprof
uses this when the Gtk instrument is selected for recording.
The 'documentation' option also guarded the man page build. Instead
if skipping the whole docs subdir skip the specific gtkdoc calls, so that the
man page build still works.
This brings it in line with the gtk3 meson build.
XInput2 is more than a decade old already, and the input improvements
there (and in every other backend really) make it untenable to have
support for X11 core input events dragging things behind.
Added two new private GtkWidget API:
* gtk_widget_add_surface_transform_changed_callback()
* gtk_widget_remove_surface_transform_changed_callback()
The intention is to let the user know when a widget transform relative
to the surface changes. It works by calculating the surface relative
transform during allocation, and notifying the callbacks if it changed
since last time. Each widget adds itself as a listener to its parent
widget, thus will be triggered if a parents surface relative transform
changes.
These flags check for code that we don't want to write, so turn them
into error flags.
Variable length arrays should be replaced by malloc() - or explicit
alloca() calls if you know what you're doing.
Implicit fallthrough should be replaced by explicit fallthrough with the
usage of G_GNU_FALLTHROUGH.
This work inspired by Kees Cook's LCA2019 talk:
https://www.youtube.com/watch?v=FY9SbqTO5GQhttp://outflux.net/slides/2019/lca/danger.pdf
This library is meant to be the new CSS library that gets used from GDK,
GSK and GTK for string printing and parsing.
As a first step, move GtkCssProviderError into it.
While doing so, split it into GtkCssParserError (for critical problems)
and GtkCssParserWarning (for non-critical problems).
The current Meson releases have broken CMake support, meaning that it is
likely that HarfBuzz could not be located for Visual Studio builds
unless one handcrafts pkg-config files for it, which is both tedious and
error-prone.
Instead, use the existing mechanism for looking for the HarfBuzz headers
and libraries on Visual Studio first when it could not be found via
dependency(), and then use the fallback if it still could not be found.
In particular, check that to_matrix() and to_2d(), to_affine() and
to_translate() return the same values.
This also requires a recent Graphene version or the tests will fail.
The tests were added when we thought we had to align memory allocations
for structures including a Graphene type in their members. Graphene
added alignment annotations for its types, and we never really used the
symbols we set after testing for allocations being aligned out of the
box with malloc(), and for aligned allocators.
Some of the flags got lost in the meson transition or were demoted from
error flags to warning flags.
This commit reintroduces them.
It also includes fixes for the code that had warnings with those flags.
The big one being -Wshadow.
Using an empty `configuration_data` object to copy a configuration file
is deprecated since Meson 0.47 (released July 2018); the equivalent
behaviour is available by using `copy: true`.
The existing post-install shell script will most likely not work on
Visual Studio builds as there is normally no shell interpreter installed
on the system where the build is done, but the build is normally done in
a standard Windows cmd.exe console.
Instead, use a Python script so that it will work on the platforms that
Python supports.
This meson port is not upstream yet, so a wrap file is not included.
Upstream has expressed interest but the port hasn't been tested on all
platforms yet. Will be added when it gets upstreamed.
Link to WIP port: https://github.com/centricular/harfbuzz
* A bunch of new variables for config.h.meson
* A check for aligned allocation being necessary at all
(graphene must use GCC vector instructions or SSE2)
* A check for C malloc() being aligned at 16-byte boundaries
* A check for a few special aligned allocator functions being
present and not being built-ins (posix_memalign is a builtin
in GCC, even on platforms where there is no posix_memalign
system function)
* Added -mstackrealign flag on Windows, since otherwise
stack variables may become unaligned when the stack briefly
passes through OS code (such as in various callbacks and
handlers)
