Skip to content

WIP: Wayland toplevel split

David Keijser requested to merge keis/gtk:wayland-toplevel-split into master

As mentioned in #2132 I wanted to try to help out getting that to move forward.

I've shuffled around some code to split GdkWaylandToplevel implementation away from gdksurface-wayland and piece by piece moved some properties over that are only relevant for top level surfaces. Still lots to do and at this stage toplevel still knows of all the internals of the surface.

But before charging head first along with this I wanted to get a sanity check of this approach from the team. Is it worthwhile pursuing?

First commit is largely only moving code around, the rest are the actual changes

I've exposed a few methods in the gdksurfacewayland.h

  • gdk_wayland_surface_get_inhibitor
  • gdk_wayland_surface_show
  • gdk_wayland_surface_update_size
  • gdk_wayland_surface_create_xdg_surface_resources
  • gdk_wayland_surface_get_xdg_surface
  • gdk_wayland_surface_get_zxdg_surface_v6
  • gdk_wayland_surface_get_event_queue
  • gdk_wayland_surface_get_window_geometry

get(z)xdg_surface is new and simply returns the xdg_surface. It's unfortunate that both variants need to be here, I'm thinking it could be one returning a union instead.

Rest is functions that was previously static

And added some virtual calls to GdkSurfaceWayland that are overriden for GdkWaylandToplevel

  • sync
  • get_window_geometry
  • configure_surface
Edited by David Keijser

Merge request reports