By setting and then getting the required version in a context, the code
was not respecting user requirements. Instead, simply get the requested
version by the user clipped by the requirements (display version)
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
The call to gdk_win32_clipboard_request_contentformats() can return NULL even
without an error condition being hit (such as when the system clipboard is
empty), so check whether the returned GdkContentFormat pointer is not NULL
before calling gdk_clipboard_claim_remote(), which expects it to be not NULL,
otherwise we face a warning from that funtion and the subsequent
g_object_unref().
This at least partially fixes issue #4796.
Add a new GdkScrollUnit enum that represent the
unit of scroll deltas provided by GdkScrollEvent.
The unit is accessible through
gdk_scroll_event_get_unit().
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
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.
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.
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
.. when creating the surface (with the HWND associated with the
newly-created surface) as well as destroying the surface (with NULL,
since the HWND is going to be destroyed), so that we can tie the EGL
calls to the HWND that we want to do the EGL stuff.
Update the functions that were updated in the previous commit to have all
GdkSurface variables named as 'surface' instead of the GTK-3.x-era window, to
make things more consistent across the board. Also fix formatting a bit.
Make the toplevel surface respond to size computations unless it is just being
created, or maximized, made fullscreen or underwent an AeroSnap operation.
This will ensure that the surface size is properly computed in time, so that
surfaces can be resized as needed.
This will fix issues 3728 and 3799.
Ensure that we take the DPI scaling into account so that surfaces will
be placed at their correct positions upon an AeroSnap operation on HiDPI
displays.
Also, use the X coordinate of the surface as-is during snap up so that
we do not inadvertently move the surface to the very left. Also fix the
AeroSnap indicator drawing for snap up so that it is drawn at the
correct places.
Since we are updating these functions, make the old GdkWindow-era
variable names to match better the names we use nowadays.
Use the debug envvar 'GDK_DEBUG=gl-egl' to determine whether we want to try to
initialize EGL first before trying WGL, as a means for people to more easily
enable EGL support on Windows to test EGL there (such as to debug the shaders,
for instance)
This will clean up the EGL code in GDK-Win32, as well as fixing crashes caused
by using an invalid EGL context in gdk_gl_context_make_current() as we did not
store up the EGL context in the correct place (lost during the transition to
the common EGL initialization code).
On the Windows/libANGLE side, the initialization of EGL has now fully moved to
the common code in GDK, but we will still default on WGL for now. Help is
really appreciated for fixing the shaders on libANGLE!
This will port the EGL code in GDK-Win32 to use the common GDK code to
initialize EGL. However, at the current state, although EGL is
correctly initialized, this code is disabled for now since
gdk_gl_context_make_current() fails as the shaders do not work for EGL
via libANGLE on Windows.
We can now clean things up in gdkglcontext-win32-egl.c as a result.
Add gdk_gl_context_is_api_allowed() for backends and make them use it.
Finally, have them return the final API as the return value (or 0 on
error).
And then use that api instead of a use_es boolean flag.
Fixes#4221
The term "hdr" is so overloaded, we shouldn't use them anywhere, except
from maybe describing all of this work in blog posts and other marketing
materials.
So do renames:
* hdr => high_depth
* request_hdr => prefers_high_depth
This more accurately describes what is going on.
We have a global GdkGLBackendType now, just set it.
This way, using the variable forces the backend type, and we don't need
special code handling the env vars in the backends.
It also means setting the env var will now "work" on GDK backends that
don't even support that GL backend and simualte another GDK backend
having registered that GL backend already. So you can run
GDK_DEBUG=gl-wgl gtk4-demo
on test what Wayland will do when WGL is in use.
Include the appropriate headers as some function prototypes were moved lately.
Also, re-order the include order of the gdk/*private.h headers alphabetically
in the files that were updated.
Creative people managed to create an X11 display and a Wayland display
at once, thereby getting EGL and GLX involved in a fight to the death
over the ownership of the glFoo() symbolspace.
A way to force such a fight with available tools here is (on Wayland)
running something like:
GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo
Related: xdg-desktop-portal-gnome#5
On Windows, GLES is not that widely available unless one installs wrapper
libraries such as libANGLE, so GLES/EGL support on Windows is used more like
a fallback mode if Desktop OpenGL (WGL) support is inadequate on the system.
Hence, unless one forces WGL or EGL, we will first try to initialize WGL, and
then try to initialize GLES if enabled and if WGL initialization failed, and
then just return whatever the last result we can obtain from these
initialization attempts, since unlike X11 EGL contexts, we do not have
separate modes for WGL except for legacy and non-legacy contexts.
We were setting the WGL pixel format in GdkWin32Display too early, so the code
does not bail out correctly when we retry establishing the WGL context.
Fix this by pushing back setting the WGL pixel format only after it passes the
shader availability check.
Should fix issue #4257.
When we initialize OpenGL, check whether we have OpenGL 2.0 or later; if not,
check whether we have the 'GL_ARB_shader_objects' extension, since we must be
able to support shaders if using OpenGL for GTK.
If we don't support shaders, as some Windows graphics drivers do not support
OpenGL adequately, notably older Intel drivers, reject and destroy the GL
context that we created, and so fallback to the Cairo GSK renderer, so that
things continue to run, albeit with an expected warning message that the GL
context cannot be realized.
Also, when we could not make the created dummy WGL context current during
initialization, make sure that we destroy the dummy WGL context as well.
Fixes issue #4165.
It is basically not used by default and is pretty much broken at this point, so
it's about time to drop it.
Let's focus on fixing the OLE2 DnD protocol.
The dummy Win32 window that we use to capture display change events and
to create dummy WGL contexts was created with CS_OWNDC, so we really do
not need to (and should not) call ReleaseDC() on the HDC that we
obtained from it, so drop these calls.
Since the shaders need to be updated for using with GLES (libANGLE at
least), default to WGL for now. Unfortunately it is not that common for
Windows to have GLES support, in which the easiest way to obtain such
support is via Google's libANGLE.
It turns out that the problem of the WGL window not drawing was due to
the fact that I messed up where I placed SwapBuffers() during the
conversion... doh:|
At the same time, stop storing the HDC in the GdkWin32GLContextWGL, but
instead always create it along the surface we created, so that it is ready
for use for operating with WGL when we are not dealing with "surfaceless"
contexts. If we are dealing with "surfaceless" contexts, just use the
HDC of the dummy window that we created when we created the
Gdk(Win32)Display.
WGL contexts should now be in working order at this point.
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:
* We are already creating a Win32 window to capture display changes,
so we can just use that to act as our dummy window that we use to
find out the pixel format that the system supports for WGL. We also
use it to obtain the dummy legacy WGL context that we will always
require to create our more advanced Core WGL contexts.
* Like what is done in X11, store up the WGL pixel format or the
EGLConfig in our GdkWin32Display.
* Ensure we do not create the dummy WGL context unnecessarily.
In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:
* For WGL, the code successfully initializes and realizes the WGL
Contexts, but for some reason things became invisible. When running
gtk4-demo, this can be verified by seeing the mouse cursor changing
when moved to spots where one can resize the window, although they
were invisible.
* For EGL, the code initializes EGL but could not realize the EGL
context as shaders failed to compile. It seems like the shader issue
is definitely outside the scope of this MR.
Now that we have the display's context to hook into, we can use it to
construct other GL contexts and don't need a GdkSurface vfunc anymore.
This has the added benefit that backends can have different GdkGLContext
classes on the display and get new GLContexts generated from them, so
we get multiple GL backend support per GDK backend for free.
I originally wanted to make this a vfunc on GdkGLContextClass, but
it turns out all the abckends would just call g_object_new() anyway.
Instead of
Display::make_gl_context_current()
we now have
GLContext::clear_current()
GLContext::make_current()
This fits better with the backends (we can actually implement
clearCurrent on macOS now) and makes it easier to implement different GL
backends for backends (like EGL/GLX on X11).
We also pass a surfaceless boolean to make_current() so the calling code
can decide if a surface needs to be bound or not, because the backends
were all doing whatever, which was very counterproductive.
... or more exactly: Only use paint contexts with
gdk_cairo_draw_from_gl().
Instead of paint contexts being the only contexts who call swapBuffer(),
any context can be used for this, when it's used with
begin_frame()/end_frame().
This removes 2 features:
1. We no longer need a big sharing hierarchy. All contexts are now
shared with gdk_display_get_gl_context().
2. There is no longer a difference between attached and non-attached
contexts. All contexts work the same way.
The vfunc is called to initialize GL and it returns a "base" context
that GDK then uses as the context all others are shared with. So the GL
context share tree now looks like:
+ context from init_gl
- context1
- context2
...
So this is a flat tree now, the complexity is gone.
The only caveat is that backends now need to create a GL context when
initializing GL so some refactoring was needed.
Two new functions have been added:
* gdk_display_prepare_gl()
This is public API and can be used to ensure that GL has been
initialized or if not, retrieve an error to display (or debug-print).
* gdk_display_get_gl_context()
This is a private function to retrieve the base context from
init_gl(). It replaces gdk_surface_get_shared_data_context().
