We no longer use the autotools 'dist-hook' to generate the items that we
need to build introspection with the Visual Studio projects, so drop the
autotools files and bits that we had to support this. So, for
introspection on Visual Studio via the project files, it is purely via
NMake at this point.
We already generate some of the sources for all builds, so extend this
to the other generated sources as well, since the Visual Studio projects
added support for generating these sources too.
Similarly, uses casts in `gtk_image_definition_unref()`. Compilation
succeeds without them, unlike in `gtk_image_definition_ref()`, because
`gtk_image_definition_unref()` is not called internally, unlike
`gtk_image_definition_ref()`. But the build would fail if some function
defined in the module were changed in the future to call
`gtk_image_definition_unref()`, and we can future-proof it now. This
also removes an inconsistency in how we access the members of the union.
`jhbuild build gtk+-3` with GCC 12 fails with:
```
In function ‘gtk_image_definition_ref’,
inlined from ‘gtk_image_definition_new_empty’
at ../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:107:10:
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:241:13: error:
array subscript ‘GtkImageDefinition {aka union _GtkImageDefinition}[0]’
is partly outside array bounds of ‘GtkImageDefinitionEmpty[1]’
{aka ‘struct _GtkImageDefinitionEmpty[1]’} [-Werror=array-bounds]
241 | def->empty.ref_count++;
| ~~~~~~~~~~^~~~~~~~~~
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:
In function ‘gtk_image_definition_new_empty’:
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:105:34: note:
object ‘empty’ of size 8
105 | static GtkImageDefinitionEmpty empty = { GTK_IMAGE_EMPTY, 1 };
| ^~~~~
```
and many similar errors.
Fix it by casting `GtkImageDefinition` to `GtkImageDefinitionEmpty` or
similar, as appropriate.
Essentially backports 4dcd02e85315f487310e2e01fe9412706a77dc35 from main to gtk-3-24.
This makes it easier to figure out those values (which are mentioned in
the GtkApplication documentation) rather than working that out from the
way they're generated (or documented as being generated).
This fixes nautilus crash and perhaps other callers issues.
Nautilus (and sometimes glib) crashes with malformed URI inside of the
bookmarks file .config/gtk-3.0/bookmarks when it has no LABEL.
This is result from the closed glib MR #2065 analysis and agreement.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2065#note_1091979
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Fixes: #4643
Unref private spool_io of GtkPrintJob before setting it to a new one
in gtk_print_job_set_source_file() and gtk_print_job_set_source_fd()
to prevent a leak.
Fixes: #4627
Instead of relying on the ones that are currently shipped with the tarballs,
generate them from their .in counterparts prior to the build. This includes
the Resource Scripts (.rc) for libgdk/libgtk, as well as gtkversion.h, in
addition to gdkversionmacros.h which can now be generated during prebuild.
This improves the source generating process by:
* Generating the sources in the libgtk build directory, so that we do not
pollute the source tree.
* Support generating gtk[private]typebuiltins.[c|h] in the Visual Studio
projects by using NMake internally.
* Update the projects and the introspection build files so that the generated
sources and headers can be found.
This will enable us to share this list with the NMake Makefiles that will be
used to generate the gtk[private]typebuiltins.[c|h] in the Visual Studio
projects.
This makes the rest of the sources that are generated being put in GDK's build
directory for the Visual Studio projects, instead of being placed in GDK's
source subdir, so that:
* We can avoid polluting GDK's source tree.
* The Visual Studio builds won't interfere with the Meson builds.
Update the project files to look for the generated sources and headers in the
right places, as well as making the introspection builds look for the generated
sources as well.
Also remove the gtk3-gen-srcs property sheets and put the relevant parts in the
corresponding gtk3-build-defines property sheets, to clean things up a bit.
Pango headers after 1.44.0 include hb.h automatically, but not before, so
re-structure the #if/#elif/#else checks for the availability of HarfBuzz 2.2.0
or later.
Pointed out in issue #4565.
Allows the application to handle "Dock icon > Quit" the same as
"Application menu > Quit".
Requires GtkApplication's `register-session` property.
Suitable replacement for gtk-mac-integration's
`NSApplicationBlockTermination` signal.
This reverts commit 749a58ab26.
This maintains feature parity with the autotools build. To achieve the
equivalent of --with-included-immodules=wayland,
-Dbuiltin_immodules=wayland,waylandgtk can be used instead.
Setting variations to their default value causes
them to show up in the serialization of the font
description - a font description has no idea about
the default values, so can't filter them out.
Avoid that.
This is a backport of the code in GTK4 where we can use the font
features that is given to us via HarfBuzz if we have Pango 1.44.x and
HarfBuzz 2.2.0 or later installed, even if we do not have PangoFT2
aavilable.
Since Pango 1.44.x depends on HarfBuzz for all platforms after 1.44.0,
we could take advantage of that and build the support in
GtkFontChooserWidget.
Add a directive that is to be used by Visual Studio compilers via the
Visual Studio projects to link to harfbuzz.lib automatically, so that
this support can be linked properly if we have the required Pango and
HarfBuzz headers and lib's installed. Meson builds via Visual Studio
should handle this automatically, since pkg-config is being used there.
Since HAVE_PANGOFT2 and HAVE_HARFBUZZ is not defined by default in the
Visaul Studio projects, we will leave it up to the user to enable them
themselves and put in pangoft2-1.0.lib and harfbuzz.lib in the project
settings by themselves, or they could use Meson, as we did before.
