We are now able to create EGL contexts properly on Windows, but not GLES. This
tries to fix things by doing the following:
* Record the GL context type in a more proper fashion, using an Enum. This
makes things a bit cleaner.
* Force GLES-3.0+ contexts, since libANGLE requires this to properly work with
the shaders-its 2.0 contexts don't work well with our shaders.
Since now we have the shaders working on Windows under GLES with libANGLE using
a 3.0+ context, drop the check to fall back to the Cairo renderer when GLES is
being used.
We only save the size when we transition from floating to fixed, so that
we can restore the size to the one prior to being fixed.
However, we should not restore to this size whenever we see a 0x0 size
from xdg_toplevel, as it can do that any time it doesn't care about the
size, e.g. when the surface is floating and just changing state.
Fix this by only using the saved size when transitioning from fixed to
floating, not when staying floating while previously floating.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4634
Calling functions inside a g_assert() means those functions will be
compiled out when building with G_DISABLE_ASSERT.
This fixes the release job in the CI pipeline.
Make GtkIMContextIME ignore ASCII control characters just like other
IMContext implementations (e.G. GtkIMContextSimple). Fixes bogus
characters appearing in text input fields (old bug 676077).
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.
gdk_wayland_toplevel_inhibit_idle() contained a contradictory assert
that always fail. More specifically, in the branch that is supposed to
create the idle inhibitor, there is an assertion that it must already
exist and that the refcount must be greater than zero. This causes a
crash on WMs/DEs that use the ZWP idle inhibit manager protocol such as
KDE Plasma and Sway. Fix this by just asserting that the refcount is
zero instead.
GtkBuilder uses GMarkup, which defines a boolean attribute value as:
- yes/no
- true/false
- 1/0
The ITS file for GtkBuilder UI definitions is only using the first pair,
likely because Glade only ever used those values. GTK's own tools, though,
will typically simplify the full yes/no and true/false strings to 1 and 0,
to minimise the parsing time.
Fixes: #4596
Various transforms are normalized with their next transform, and if they
end up being the identity transform will return NULL.
For example a translation by (x,y,z) and followed by (-x,-y,-z) will
result in NULL.
This makes the hotspot of DND surfaces work when using the Vulkan and
OpenGL renderers.
This bumps the CI image used to the newly built image. This is needed to
install a new enough libwayland-client.so needed for wl_surface.offset.
This is done by adding wayland as a meson subproject, building it
on-demand if the version in the system is not new enough. As
libwayland-client.so is pulled in implicitly when linking to gtk4, the
compile step needs LD_LIBRARY_PATH set to make ld find the right library
to link to.
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 https://gitlab.gnome.org/GNOME/gtk/-/issues/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 https://gitlab.gnome.org/GNOME/gtk/-/issues/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
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.
See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4338
Unref private spool_io of GtkPrintJob before setting it to a new one
in gtk_print_job_set_source_file() and gtk_print_job_set_source_fd()
to prevent a leak.
Fixes: #4627
