Instead of performing keyboard layout substitution whenever we find a matching
entry in the registry, first try to load the original layout and only attempt
substitution when that fails.
See #4724
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
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
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
MinGW-w64 CRT provides no 'hid.lib' file. Instead, it has 'libhid.a'
which can be linked with '-lhid' linker argument.
Also, we have to declare the '_LIBADD' variable and add 'LDADDS' to it,
or 'LDADDS' won't do anything for the build.
Note that gdk_monitor_get_geometry () returns DPI-scaled values,
while the screen offset should be unscaled, as scales are properties
of indivdual monitors.
An arithmetic operation involving a signed and an unsigned operand
of the same rank will have both operands converted to *unsigned*.
That's an issue if the signed operand actually has a negative value.
That was causing issues with the handling of monitor geometries that
had negative x / y positions.
...if GLES (libANGLE) support was enabled in the build. This way, we can
check whether the GL driver is capable enough to support the OpenGL
features that we use in GTK. If the driver is not capable enough, and
GLES support is enabled, we can try to create the GdkGLContext again as a
GLES context.
Group the WGL-specific code and GLES-specific code together, so that we
can reduce the number of #ifdef ... in the code, to make the code more
readable and easily maintained. This will pave the way to add a
fallback mode to use libANGLE (OpenGL/ES) in case the Desktop OpenGL
support is inadequte, if OpenGL/ES support is enabled in the build.
This is somewhat based on the updates that were done in GTK master, so
we are using one subclass for WGL-based GdkGLContexts, and another for
GLES-based GdkGLContexts.
Also remove the underscores in many of the functions in
gdkglcontext-win32.*.
Clean up the code a bit as a result.
Like the recent updates in GTK4, the HWND that we use to obtain the HDC
that we need for OpenGL/GLES operations should really be tied to
GdkWindow, not GdkDisplay, as that is where the Win32 HWND where we
originate from is located, so stop storing the GL HWND in
GdkWin32Display, but just grab them from the GdkWindow that is bound to
the GdkGLContext.
We are more conservative about freeing up GL resources in GTK3, so we
will continue to call ReleaseDC() as we did before.
It apparently worked by chance in the past, but now causes e.g.
alphanumeric characters to be interpreted as half-width katakana
when using the Japanese IME.
