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 source listing is not likely to change for this one, so clean up the
build files a bit, and make the gtk3-icon-browser MSVC project a
complete one instead of a template.
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/
GNOME Shell 3.32 will remove support for the app menu
so we need to move its contents to the primary (hamburger)
menu.
widget-factory already had a primary menu.
The only item in the app menu was About.
https://gitlab.gnome.org/GNOME/Initiatives/issues/4
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 patch moves the "Copy to Clipboard" button into the same container
as the description label, to centre the button regardless of the number
of icons shown in the grid.
https://bugzilla.gnome.org/show_bug.cgi?id=789134
When making mockups for GNOME apps in Inkscape, looking for symbolic
icons is a common task. Searching for icons in the file system is clumsy,
and icon-browser provides a much better interface for finding them.
However, currently there is no way to insert the symbolic icons as SVG
directly from icon-browser, so right now it is only useful for finding
the name.
This patch adds a sixth column to the modal window that appears when
clicking a symbolic icon. The icon in this column is labeled "scalable",
and dragging it onto another window results in the vector icon URI being
inserted.
This enables a much simpler workflow when designing with symbolic icons.
https://bugzilla.gnome.org/show_bug.cgi?id=778930
It was in both [general] with a description and [other] with none.
Leave it in [other] with the other folder- icons, + the description.
bonus: this makes all of [general] fit in our default window size!