Skip to content
Commit 3c67cc13 authored by David Edmundson's avatar David Edmundson
Browse files

Support XDG v6

Summary:

The main clever part that's not just boring boiler plate is how we
handle the structure change
A surface now has an XDGSurface which then has a an Xdg TopLevel or a
Xdg Popup

We need to fit this into the public API which assumes a surface has a
Surface or a Popup.
The old Surface is similar to the new TopLevel.

The shoehorning works by relying on the fact that a surface without a
role is pretty useless.

Clients create the surface implicitly with the toplevel or implicitly
with the popup.
The server only announced it has a new "XdgSurface" when it gets a new
zxdg_surface_get_toplevel.

----

Popup decisions:
- On popup creation the server should copy the current info from the
positioner and then it gets deleted. Given kwaylands job is to keep
state, we expose all these parameter via popup.

- Due to this positioner is not exposed as a resource anywhere.

- Server API is 100% backwards compatiable.
i.e new code will work identically with v5 clients.

- Client API is not.  Grabs are called separately from the constructor,
and the parent surface changed to an xdgsurface, not a raw surface.
V5 code still works as-is, just not with the new constructors.

It seemed better to match the v6 (and what will be the stable v7) than
to try and do hacks and lose functionality.
Given the client needs to change the code to opt into V6 anyway. I don't
think this is a huge problem.

Test Plan: Current test still passes.

Reviewers: #plasma, graesslin

Reviewed By: #plasma, graesslin

Subscribers: graesslin, mart, plasma-devel, #frameworks

Tags: #frameworks, #plasma_on_wayland

Differential Revision: https://phabricator.kde.org/D6047
parent f1491e00
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment