This is largely adapted from commit 83027c68f1 ("11: Implement
inhibit_system_shortcuts API"), with similar rationale:
To implement the inhibit_system_shortcuts API on X11, we emulate the
same behavior using grabs on the keyboard.
To avoid keeping active grabs on the keyboard that would affect
other X11 applications even when the surface isn't focused, the X11
implementation takes care of releasing the grabs as soon as the
toplevel loses focus.
Note that Windows has low-level keyboard hooks that could help achieve
the expected behaviour. This is implemented by spice-gtk & gtk-vnc for
example, but correctness isn't obvious. I left a TODO comment.
This patch helps implementing remote desktop widgets with GTK4, since
currently on win32 backend Alt-Tab and such are always left to the
system unless there is keyboard grab (which can't be requested by the
client API anymore, afaict).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This function is probably not generally useful for a Gtk+/win32 user,
and it's only used internally by gdk-win32. It's time to deprecate it, I
believe.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The function isn't used by Gtk itself anymore, and does not help much.
It creates extra issues for bindings, as it doesn't fit well with code
doing the same job for other objects.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
.. 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.
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.
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.
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.
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.
Make _gdk_win32_display_get_monitor_scale_factor() less complex, by:
* Drop the preceding underscore.
* Dropping an unused parameter.
* Using a GdkSurface instead of a HWND, as the HWND that we pass into
this function might have been taken from a GdkSurface, which are now
always created with CS_OWNDC. This means if a GdkSurface was passed
in, we ensure that we only acquire the DC from the HWND once, and do
not attempt to call ReleaseDC() on it.
* Store the HDC that we acquire from the GdkSurface's HWND into the
surface, and use that as the HDC we need for our GdkGLContext.
* Drop the gl_hwnd from GdkWin32Display, as that is really should be
stored in the GdkSurface.
* For functions that were updated, name GdkWin32Display variables as
display_win32 and GdkSurface variables as surface, to unify things.
* Stop calling ReleaseDC() on the HDC that we use for OpenGL, since
they were acquired from HWND's created with CS_OWNDC.
If we are undergoing a surface move, just apply the next_layout anyways,
even if we are not moving a toplevel surface.
Update the way how we obtain the x and y coordinates of a surface, if it
is a toplevel, apply the x and y coordinates from the results from we
obtained the underlying Win32 HWND, as we did before. But if it is a
popup, use gdk_win32_surface_get_geometry() to obtain the correct x and
y coordinates to place our popup surface.
Also correct how we compute the shadow dimensions, and the final popup
rectangle as we attempt to layout the popup surface, since GDK-Win32
keeps track of the shadow dimensions in system (unscaled) units, not GDK
units.
Fixes issue #3793.
We ought to get the coordinates of where the window menu should be
displayed using gdk_win32_surface_get_root_coords(), instead of rounding
the position that we obtained with gdk_event_get_position().
Also rename items a bit in the same function, and call
gdk_event_get_event_type() for consistency with the other backends.
Fixes issue #3704.
This attempts to fix the counter-intuitive resizing of surfaces in GTK4 where
the surface grows or shrinks at the right and/or bottom edge when the window
resized from the top and/or left edge(s).
This is not yet perfect as the window stutters upon resizing from the top
and/or left edges, but at least makes resizing more intuitive.
Remove the 'resized' member from the GdkWin32Surface structure, as we already
have a structure with a member that keeps track of whether a surface is being
resized, so we can just use that and avoid some confusion in the process
In GTK4, we are now defaulting to the OpenGL renderer with the Cairo renderer
only used as a fallback, so there is no point keeping the code paths that use
layered windows as layered windows do not work well with OpenGL nor Vulkan.
Have an implementation of ->request_layout() and ->compute_size() for the Win32
surface backend so that we can properly display and move and resize the
windows, as we request from the Win32 APIs.
Hxndling Aerosnap properly is mostly done except for snap_up(), which needs to
to be looked at later.
