CI and downstream packagers have been using the Meson build for a while
now, and we checked that it's idempotent to the Autotools build.
Having two build systems in tree doesn't make maintaining and releasing
GTK any easier, even if it's the stable/frozen branch.
We don't need to track the project files and property sheets that are generated
from their templates, and we don't want to track the demos.h(.win32) that are
mainly used for the Visual Studio builds, which are also generated.
The Visual Studio projects have support for generating these, especially
that the encoded string that result from them may become too big for the
Visual Studio compiler to handle (such as for gtk3-demo) and we are normally
supposed to generate the GResources sources for all builds, as the
generated code depends on the compiler being used).
The Pango headers prior to 1.44.0 do not include the HarfBuzz headers, so we
need to re-structure how we check for HarfBuzz 2.2.0 or later if we have Pango
1.44.x or later.
Fixes issue #4565.
...even if PangoFT2 is not present, provided that Pango 1.44.0+ and
HarfBuzz 2.2.0+ are installed. The demo now has added support for later
Pango versions that use HarfBuzz for shaping on all supported platforms.
...if Pango 1.44.0+ and HarfBuzz 2.2.0+ are available, otherwise we
stick on to the current code path.
This way, we can have people build and run the demo even without
PangoFT2 if Pango 1.44.0 or later and HarfBuzz 2.2.0 or later is
installed.
This way, we can share the demo listing to be used in other build
Makefile-based build systems, such as the auxiliary NMake Makefiles used
to generate the various sources.
Various files are in git but not in dist tarballs. Some of them look
like potentially useful references for downstream distributors.
Signed-off-by: Simon McVittie <smcv@debian.org>
open() in text mode should never be used without an encoding because it defaults
to the locale encoding which is rarely what is wanted.
This fixes the Windows build in some cases (depending on the locale/paths used)
Comments matched to reassure the compiler that fallthrough is
intentional are supposed to precede the case or default keywords, at
least in GCC, so the one here did not suppress the warning with GCC. We
can just the if condition and put the comment at the end to solve that.
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
If we detect HarfBuzz and PangoFT2, GtkFontChooserWidget uses them. So
we need to add CFLAGS and LIBS of them to GTK_DEP_CFLAGS/LIBS. If we
don't add them, MinGW build fails to link.
...in place of math.h, as we are using round(), which is possibly not
provided by the compiler since we don't require a C99 compiler in
GTK+-3.x and gtk/fallback-c89.c does include math.h anyways.
This class is not added by any widgets nor themed by Adwaita/HC.
However, it is presented here as if it does something. It doesn’t.
But we changed the 2 buttons with the .raised class to use symbolic
icons, unlike their ‘unraised’ counterparts, which is unnecessarily
confusing and might make people think .raised affects icons somehow.
So, make them use the same icons in all cases; that way, if .raised is
ever made to do anything, 6 years later, what it does will be clear.
https://bugzilla.gnome.org/show_bug.cgi?id=644248
