This uses CVDisplayLink to drive the GdkFrameClock. A GdkWindow
can register a frame callback to thaw their frame clock as necessary
based on the next notification from CVDisplayLink.
CVDisplayLink notifies us on a high-priority thread. We use the same
NSEventas gdkeventloop-quartz.c to wakeup the main loop. This is done
so that we don’t pathologically wake up the select thread to then
continue notifying the main loop.
We use an embedded GList node in the GdkWindowImplQuartz so that we
can avoid allocating any lists or arrays for pending frame callbacks.
Compare this to the same design in GdkWindow for children.
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.
Now that we have a frame clock in place, we should be able to drop
the beam-sync penalty prevention code as we should be aligning our
draws with CVDisplayLink.
Originally by Christian Hergert <chergert@redhat.com>, flushWindow
corrections and improvements by John Ralls.
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
When commit 49589e1da added support for the new high-contrast key,
it missed that the getter should only use the setting directly when
not going through the portal.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4651
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.
On Wayland it is a protocol violation to upload buffers with
dimensions that are not an integer multiple of the buffer scale.
Until recently, Mutter did not enforce this. When it started
doing so, some users started seeing crashes in GTK apps because the
cursor theme ended up with e.g. a 15x16 pixel image at scale of 2.
Add a small sanity check for this case.
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.
