.. 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.
In line with what is done with the Wayland backend, enable the mapped state
independently as needed from the toplevel surface presentation, and also enable
the mapped state if necessary when presenting the popup surface.
When being fullscreen, and wanting to unfullscreen but not caring about
whether to go unmaximized or maximized (as this information is lost), if
the GdkToplevelLayout represents the full intended state, we won't be
able to do the right thing.
To avoid this issue, make the GdkToplevelLayout API intend based, where
if one e.g. doesn't call gdk_toplevel_set_maximized() with anything, the
backend will not attempt to change the maximized state.
This means we can also remove the old 'initially_maximized' and
'initially_fullscreen' fields from the private GtkWindow struct, as we
only deal with intents now.
It was used by all surfaces to track 'is-mapped', but still part of the
GdkToplevelState, and is now replaced with a separate boolean in the
GdkSurface structure.
It also caused issues when a widget was unmapped, and due to that
unmapped a popover which hid its corresponding surface. When this
surface was hidden, it emitted a state change event, which would then go
back into GTK and queue a resize on popover widget, which would travel
back down to the widget that was originally unmapped, causing confusino
when doing future allocations.
To summarize, one should not hide widgets during allocation, and to
avoid this, make this new is-mapped boolean asynchronous when hiding a
surface, meaning the notification event for the changed mapped state
will be emitted in an idle callback. This avoids the above described
reentry issue.
This removes the GDK_CONFIGURE event and all related functions and data
types; it includes untested changes to the MacOSX, Win32 and Broadway
backends.
This removes the gdk_surface_set_shadow_width() function and related
vfuncs. The point here is that the shadow width and surface size can now
be communicated to GDK atomically, meaning it's possible to avoid
intermediate stages where the surface size includes the shadow, but
without the shadow width set, or the other way around.
Call SetCapture() explcitly for the (new) modal window so that we make the
modal window respond to mouse input, and also call SetCapture() to the parent
of the transient window that we are destroying so that mouse input capture is
returned to the parent window.
This attempts to fix the following:
* Upon creating a new modal window, the new modal window does not receive
pointer input unless one switches to another program and back
* Upon closing a transient window, the parent window that activated the
transient window does not receive pointer input unless one switches to
another and back
This reverts commit fc2008f2.
Turns out, we *don't* have code to maintain Z-order. Restacking
code is not doint that, it just enforces a few weird Z-order-related
behaviours.
Make sure that we get the state of the modal window properly, and send out the
corresponding notification signals.
This will ensure that we do not try to activate windows that should have become
inactivated due to it opening modal windows and render the program unresponsive
because we are not activating the correct window that is due to receive user
input.
Prevents GDK Popups from stealing focus from the parent window when
using Server Side Decorations on win32.
It uses `ShowWindow` and the `SW_SHOWNOACTIVATE` flag.
Since the changes to GDK to use surface subtypes, CSD windows were
broken because we did not set the window styles properly. Fix this by
first acquiring whether decorations are used by the GtkWindow, and based
on that result we set the decorations that we want to use accordingly
and so apply them.
Thanks to Matt Jakeman for investigating into the issue and providing
pointers to a proposed fix.
Fixes issue #3157, besides the part where window sizes are not correct
since that is likely caused a separate issue.
