Some Windows keymaps have bogus mappings for the Ctrl modifier. !4423 attempted
to fix this by ignoring the Ctrl layer, but that was not enough. We also need to
ignore combinations of Ctrl with other modifiers, i.e. Ctrl + Shift. For example,
Ctrl + Shift + 6 is mapped to the character 0x1E on a US keyboard (but it should
be treated as Ctrl + ^). Basically, always ignore Ctrl unless it is used in
conjunction with Alt, i.e. as part of AltGr.
Related issue: #4667
Some keymaps on Windows contain bogus mappings for Ctrl+key for certain
keys, e.g. Ctrl+Backspace = Delete, or Ctrl+[ = 0x1B. These are never
used on Windows, so we should ignore them.
Fixes#4667
The actual code that does the IM context code handling on Windows now uses the
native Windows APIs to handle keystrokes, so this patch is no longer needed, as
it was found that it instead caused issues.
Pointed out in issue #2865.
This reverts commit fd6ce9975e.
For some users, GetKeyboardLayoutNameA() returns an alias instead of the
fully resolved keyboard layout identifier. In that case, we have to
query the registry to resolve the alias before we can look up the DLL
path.
See comments under #4610
Contrary to what you can read on the internet, SGCAPS keys don't work
by having capslock toggle the KBDCTRL bit, they actually have two
consecutive table entries, the first of which is for the normal
version and the second of which is for the capslocked version.
Background: SGCAPS is short for Swiss German caps because Swiss German
was the first layout to use this feature. For keys with the SGCAPS flag,
capslock has a different effect than pressing shift. For example:
Shift + ü = è, CapsLock + ü = Ü, CapsLock + Shift + ü = È
DLL loading failures should not happen under normal circumstances, but
we should at least try not to crash and and print better diagnostic
messages if they do happen.
See #4610
Previously, we treated CapsLock and KanaLock as part of the global
keyboard state, much like NumLock and ScrollLock, rather than using
the supplied modifier mask. This was because GDK does not have a
modifier mask for KanaLock, only for CapsLock, so it would not have been
possible to properly support it.
However, this approach ended up causing problems, with certain keyboard
shortcuts not registering when capslock was active. This was first
observed in Inkscape [0] and appears to affect shortcuts consisting of a
single key (like 'a') with no additional modifiers (wheareas shortcuts
like 'ctrl+a' work).
So now we are using the supplied GDK_LOCK_MASK instead, and dropped
support for KanaLock, which we probably don't need anyway (since regular
text input should be handled by the IME input module -- the keymap is
mainly for shortcuts and keybindings, where you don't really want
KanaLock).
[0] https://gitlab.com/inkscape/inkscape/-/issues/3082
gdk_win32_keymap_get_entries_for_keycode() did not initialize n_entries,
which led to a wrong number of items being returned in some cases.
/fixes #4610
If we ended up on no output at all, keep the HiDPI scale as is, as it
likely means we were on a workspace that was switched away from. By
keeping the same scale, we avoid unnecessary scale changes that would
otherwise take place if the scale when on monitors would end up being
more than 1.
This will enable us to not confuse with the deprecated headers in
gtk/deprecated as those headers are also listed under deprecated_h_sources in
gtk/deprecated/Makefile.inc, when we include the makefile snippets in both
gdk/ and gtk/.
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.
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
