Like what was done in the *.vcxprojin templates, consolidate project configs
that are repetitive, and use the 'Condition=' directive to distinguish between
configuration and/or target platform differences.
...for Visual Studio 2010 and later, since we used to copy them and
merely update the value of $(VSVer) during 'make dist' as needed.
Instead of doing that, move the property sheets for Visual Studio 2010,
which is the base version that we use, into a directory of its own, and
make the Visual Studio 2010~2022 projects look for them in that
directory, and set VSVer according to the toolset version identified by
each of the project files.
The ARM64-specific property sheet needed for VS2017 and the VS2008
property sheets will remain as they are.
We can again use MSBuild trickery to do what was done in the dropped
property sheet.
Unfortunately, like the last commit, I couldn't figure out a way do to
something similar in the VS2008 project files... :|
... and so stop using gtk3-install.[vsprops|props], and remove that
property sheet from the dist and dist the NMake Makefile for the
purpose.
Also remove win32/vs10/gtk3-install.vcxproj.filters as well, as it is
no longer needed.
We will remove the gtk3-install.[vsprops|[props][.in] in a subsequent
commit.
This is an NMake Makefile that will replace the property sheets in the
Visual Studio project files so that we can call it from the project
files to "install" the binaries and introspection files that were built,
along with the header files and other data files, which aims to be
easier to maintain for the current approach.
This will also be expanded upon to optionally build the translation
files and make the installed files more in-line with what are done in
the Meson build files, where there could be compatibility problems with
older Visual Studio toolchains.
If we get consecutive preedit string updates that announce a NULL
string, we still do end up issuing ::preedit-changed with those.
Ignore changes from NULL to NULL, it is the other combinations which
must issue this signal.
For reasons that only apply to the old serial handling, asking for
the surrounding after IM changes resulted in lazy handling of
commit() afterwards.
With the recent interpretation of serials, this problem became more
apparent, since it is in fact very likely that the last interaction
step after an IM change is notifying of the changed surrounding
text after the IM change was applied.
Make handling of surrounding text similar to caret position changes,
always commit() after the state change, but skip through non-changes.
This makes the compositor state fully up-to-date after an IM change.
(cherry-picked from commit eb7c78aa4896b1d36fa09a3e68c942730b233f74)
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.
