As per Benjamin's suggestions, cleanup the previous implementation on
initializing the GLES context on Windows, so that we use more items that are
already in GDK proper and integrate two functions into one.
Instead of first trying to explicitly ask for a WGL 4.1 context, ask for
the WGL context version that matches what is reported via
epoxy_gl_version(), so that we get the maximum WGL version that is
supported by the graphics drivers, and make sure any WGL contexts that
are shared with this (initial) WGL context are created likewise.
We can try to do a default-bog-standard 3.2 core WGL context creation
if the need arises, but let's leave that alone for now.
The EGL context that we are actually creating must have matching OpenGL/ES
versions and allowed GL API set with the previously-created EGL context
that will be shared with it so that they can interoperate together, if
applicable.
This will fix the situation by making sure that we request for the
OpenGL/ES version and OpenGL API set that match with what we have in our shared
EGL context. Otherwise, the newly-created EGL context assumed a OpenGL/ES 2.0
context that supported desktop OpenGL, which may not be what we wanted, such as
in the case of libANGLE.
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
