My reading of the code is that gdk_drop_new() is not
consuming the content formats it is given, so the caller
must not pass a new reference.
Needs testing on Windows.
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.
Reading the comment, it seems to be related being a window manager
decoration utility; this is not something GTK4 aims to handle, just drop
support for this.
The keycode and modifier (state) parameters are in the wrong order
for gdk_key_event_new() in the gdk win32 backend, which causes
key up/down events to be populated incorrectly.
In gdk/win32/gdkmonitor-win32.c in function
populate_monitor_devices_from_display_config() refresh->Numerator * 1000
overflows for refresh->Numerator > 4294976.
Cast the factor 1000 to UINT64 to prevent the overflow.
Fixes#3394
In gdkdevice-win32.c we are interested in knowing which window
receives mouse input at a specific location.
Only WindowFromPoint is the right API for the task, other API's
(such as (Real)ChildWindowFromPoint(Ex)) have shortcomings because
they are really designed for other purposes. For example, only
WindowFromPoint is able to look through transparent layered windows.
So even if we want to find a direct child we have to use
WindowFromPoint and then walk up the hierarchy.
Fixes: #370, #417
See: !2800
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.
GTK will not up front know how to correctly calculate a size, since it
will not be able to reliably predict the constraints that may exist
where it will be mapped.
Thus, to handle this, calculate the size of the toplevel by having GDK
emitting a signal called 'compute-size' that will contain information
needed for computing a toplevel window size.
This signal may be emitted at any time, e.g. during
gdk_toplevel_present(), or spontaneously if constraints change.
This also drops the max size from the toplevel layout, while moving the
min size from the toplevel layout struct to the struct passed via the
signal,
This needs changes to a test case where we make sure we process
GDK_CONFIGURE etc, which means we also needs to show the window and
process all pending events in the test-focus-chain test case.
gdk_gl_context_has_framebuffer_blit() and gdk_gl_context_has_frame_terminator()
were only used by by GDK/Win32, and they do not provide performance advantages
in GTK master, so clean up the code a bit by dropping them.
Use gdk_surface_get_geometry() to get the correct x and y coordinates of the
window that we are resizing, so that the window does not reposition itself
automatically at the top-left corner at resizing as we to used hard-code the x
and y coordinates to 0.
By doing so, we ensure that resizes of windows will work on Vulkan renderer, by
first calling gdk_win32_surface_handle_queued_move_resize() before we proceed
as usual
Use the shared function that was added in the previous commit, to simplify
things.
Also make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() back into static functions, since
they are now used only by the code in gdksurface-win32.c
Since we need to deal with queued moves and resizes in the Cairo, GL and Vulkan
draw contexts, and the logic involved in all three of these are largely
similar, add a function gdk_win32_surface_handle_queued_move_resize() that will
handle this, which will be shared between these three types of draw contexts.
Move gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() to gdksurface-win32.c, since these
functions are not only used for Cairo draw contexts, but is also used for GL
draw contexts, and will be used for Vulkan draw contexts.
