We now have a boolean setting that determines whether the high-contrast
theme should be used. Support it by automatically setting the existing
`gtk-theme-name` and `gtk-icon-theme-name` properties when enabled.
With that, it is no longer necessary to change the regular theme settings
for high-contrast, so toggling between high-contrast and a non-default
theme finally works reliably.
`gdk_quartz_display_get_monitor_at_window` crashes when it tries to access the NSWindow on
an offscreen window. The attribute `toplevel` of `impl` is uninitialized and
causes a segfault.
This partially fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/7608
Windows keymaps contain some bogus mappings, e.g. Ctrl+Backspace=Delete.
Previously, we correctly identified the key as Backspace, but the Ctrl
was still consumed, so the Ctrl+Backspace keybinding did not work.
gdk_win32_keymap_translate_keyboard_state erroneously used the active
group rather than the specified group, which caused shortcuts not to
work in Inkscape when using a Cyrillic layout.
This consolidates the check for the running CPU in one single location,
to make things a bit cleaner, as:
* We can make use of IsWow64Process2(), if available, to check both
whether we are running on an ARM64 CPU, and whether we are running as
a WOW64 process. This is also the function to use to properly check
whether we are running as a WOW64 process on ARM64 systems, as
IsWow64Process() does not work as we want on ARM64 systems.
* If we don't have IsWow64Process2() (which is absent from Windows prior
to Windows 10 1511, where ARM64 Windows is introduced), we can fall
back to IsWow64Process(), which will tell us whether we are running
as an WOW64 process (but clearly not on an ARM64 system).
Also clean up things a bit so that we can reduce reliance on global
variables.
The old code used repeated calls to `ToUnicodeEx` to populate
the translation table, which is slow and buggy. The new code
directly loads the layout driver DLLs from Windows.
Associated issues: #2055#1033
Merge request: !1051
GdkWin32Keymap cleanup
Conform to C89, improve comments, whitespace
When a selection request fails to be converted to the requested format in the
GTK layers, the wayland backend would miss bumping the machinery to handle
further pending selection requests. Fix this by reacting to
GdkDisplay::send_selection_notify with target=GDK_NONE (i.e. a failed
conversion as hinted from the upper layers) to do that.
This ensures the clipboard handling doesn't lock up in the following
scenarios:
- GTK returned with a mismatching type to the one requested
- GTK fails to convert to the requested type
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4340
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.
Rename README_EGL_MSVC.txt to README_FEATURES_MSVC.txt, as we now have
more features that can be included in the builds using the Visual
Studio projects, which require additional depedencies and manual
enabling.
Specifically, this outlines how the font tweaking feature in libgtk can
be enabled and for people who wish to do so, how to enable the Font
Features demo in gtk3-demo.exe.
...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.
We can regenerate demos.h.win32 with or without the font features demo
by using the regenerate-demos-h-win32 target with or without secifying
the FONT_FEATURES_DEMO=1 flag on the NMake command line.
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.
...in the libgtk3 project, so that we can automatically link to
harfbuzz.lib if we have a sufficiently-new version of Pango and HarfBuzz
installed, so that the code to enable font features can be linked
properly, even if we don't explicitly put harfbuzz.lib in the list of
libraries that we feed into the linker in the project files.
If one is using pre-Pango-1.44.x and/or pre-HarfBuzz-2.2.0 and intends
to enable font features support, one still must update config.h.win32 to
make sure HAVE_PANGOFT2 and HAVE_HARFBUZZ is defined, and put
pangoft2-1.0.lib, harfbuzz.lib and freetype.lib (or so) in the
"Additional Libraries" under the linker settings in the projects
manually, as required before.
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.
