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
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.
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.
If we ended up on no output at all, keep the HiDPI scale as is, as it
likely means we were on a workspace that was switched away from. By
keeping the same scale, we avoid unnecessary scale changes that would
otherwise take place if the scale when on monitors would end up being
more than 1.
As far as I can tell, the code here is redundant and probably ended up
this way for historical reasons. A drag surface without
`->is_drag_surface` would be created if `gdk_display_create_surface`
were called with `GDK_SURFACE_TEMP`, but drag surfaces never seem to be
created that way.
In `gtk4-demos`, drag and drop and popovers seem to be working normally
with this.
Otherwise if we hide and show a window we recreate a new surface,
breaking the compositor's association, but potentially not resend this
data for the new surface.
This matches what we do for input_region.
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.
The code to create and manage a fake egl surface to bind to is
complex and completely untested because everyone seems to support this
extension.
nvidia and Mesa do support it and according to Mesa devs, adding support
in a new driver is rather simple and Mesa drivers gain that feature
automatically, so all future drivers shoould have it.
We were calling _gdk_surface_update_size() every frame, even if the
window size didn't change. This would cause us to discard all cached
buffers and redraw the whole screen.
This was BAD.
This adds a "release" destructor for the gtk_surface1 interface which
signals to the server that a surface has been destroyed on the client
side, which the current "destroy" does not do.
Ideally the protocol would have specified a destroy request marked as
destructor to handle this automatically, however this is no longer
possible due to the destroy method being implicitly generated in the
absence of an explicit request in the protocol. Adding a destroy request
marked as destructor now would generate a new destroy method that
unconditionally would send the request to the server, which would break
clients running on servers not supporting that request.
Some GTK based applications such as Qemu UI create and manage
EGLSurfaces associated with the relevant GdkSurfaces. In order to create
an EGLSurface, there needs to be a way to pass the native window
object to eglCreateWindowSurface(). While running in an X environment,
the native window object can be obtained by calling
gdk_x11_surface_get_xid(). Likewise, the native window object can be
obtained by calling gdk_wayland_surface_get_wl_egl_window() while
running in a Wayland environment. Therefore, this API needs to be
exposed to apps.
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
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.
We only called xdg_toplevel.(un)set_maximize() if the toplevel layout
changed, but this misses the case when the compositor had changed the
maximized state. Change it to call the xdg_toplevel request if either
the local layout changed, or if the layout differs from the current
state.
This fixes an issue where one couldn't unmaximize a window by double
clicking the titlebar that, had previously been maximized e.g. using a
keyboard binding.
Do the same for fullscreen.
If compute_size() returns TRUE, the layout will not be propagated to
GTK. This will be used by the X11 backend to queue asynchronous resizes
that shouldn't yet allocate in GTK.
Not doing this means the next time the same surface is shown, if the
shadow size wasn't changed, it wouldn't be sent to the compositor, which
then would result in compositor deriving its own window geometry which
would include the shadow margin.
This fixes an issue where the file chooser dialog would grow each time
it opened.
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.
GTK4 doesn't support arbitrary constraints when resizing a window (e.g.
steps, or aspect ratio), so we don't need to care about the result from
compute-size when doing interactive resizing.
