The plan is to concencrate size computations as part of the frame clock
dispatch, meaning we shouldn't do it synchronously in the present()
function.
Still, in Wayland, and maybe elsewhere, it is done in the present()
function, e.g. when no state change was made, but this will eventually
be changed.
Mapping a surface under Wayland is an asynchronous process, where one
creates a surface and commits an initial state without having drawn
anything, then waiting for a configuration, which then is acknowledged
and content is painted and committed. Not until having received this
configuration is a surface actually mapped, so wait with setting the
mappedness until this.
Use the set_minimized method of the xdg_toplevel
interface to implement minimization as well as possible.
It is not possible, since there is no corresponding
state that we could use to update our surface state,
but in practice, it works well enough.
Fixes: #2688
This commit fix the warning:
../gdk/wayland/gdkdisplay-wayland.c:1079: Warning: GdkWayland: gdk_wayland_display_set_cursor_theme: unknown parameter 'name' in documentation comment, should be 'theme'
The 'has_uncommitted_ack_configure' state was added to make sure we're
responding to 'xdg_surface.configure' events with
'xdg_surface.ack_configure' requests, as is necessary according to spec.
What we didn't do was to clear this state when hiding, meaning that if
we hid the surface after a configure event, but before the frame
finished and we processed the 'has_uncommitted_ack_configure', we'd try
to acknowledge the surface configuration after having destroyed the
surface.
Closes: #3262
The GdkWayland API takes generic GDK types and performs a run time
check, which means we need to properly annotate the actual expected
type in order to have methods recognised as such.
When using the saved size because the compositor
told us to, we were forgetting to readd the margins.
The visible symptom of this was the window getting
smaller every time we went to tiled state and back.
Don't remember the surface size when we are in tiled
state either. This matches the 'fixed_size' condition
in gdk_wayland_surface_configure_toplevel.
This change fixes an issue where moving a window first
to tiled, then to maximized state and back would lead
to the unmaximized window having the tiled dimensions.
We should not emit configure events before we are realized - size
changes at this point are not relevant.
This gets rid of a mysterious emission of GdkSurface::size-changed
with a size of 52x52, that is happening when GtkWindow sets the
shadow_width before the window is mapped.
Most of the surface api we have in the Wayland backend
only makes sense for toplevels, so reshuffle things to
take a GdkToplevel instead of a GdkSurface.
Update all callers and the docs.
We must wl_surface.commit after xdg_surface.ack_configure to make it
have an effect. We failed to do so when a configure event didn't result
in new updates, so make sure we fall back on an simple
wl_surface.commit if there was no new actual frame painted.
Closes: #2910
In order to make the cairo renderer/context behave more similar to how
the OpenGL and Vulkan renderer/context behaves, request a frame callback
and commit in the end frame vfunc.
This means the end frame vfunc in cairo does
* attach buffer
* request frame callback
* sync surface state
* commit
Where as e.g. the OpenGL version of the same flow does
* attach buffer
* request frame callback
* sync surface state
* eglSwapBuffers()
where eglSwapBuffers() indirectly calls wl_surface_commit().
When using the gdk_display_close(), the handle to the Wayland compositor was not released. This could cause the consumption of all available handles, preventing other processes from accessing the display.
Fixing this by calling wl_display_disconnect() when releasing the GdkWaylandDisplay object.
Signed-off-by: Julien Ropé <jrope@redhat.com>
Handle both these settings, and the older settings-daemon ones for
backwards compatibility. The keys are already checked for existence
in the schema, so it will just use the existing ones.
Prefer this location, but also look for the old location in
settings-daemon for backwards compatibility. This applies to both
direct settings lookups and via the settings portal.
