xdg-decoration: allow get_toplevel_decoration with a mapped toplevel

When clients create an xdg_toplevel_decoration object, they opt-in for
being self-decorated by the compositor if it decides to. Clients have no
way to prevent the compositor from potentially decorating them, if they
don't want any decorations they should destroy the
xdg_toplevel_decoration object.

Some toolkits allow toggling toplevel decorations at runtime. In this
case they need a way to transition from having no decorations at all to
a state where they can be decorated.

Allow creating an xdg_toplevel_decoration object on an already-mapped
toplevel to accomodate for this use-case.

Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/issues/9
This commit is contained in:
Simon Ser 2020-02-14 12:22:03 +01:00
parent b0a25f26d3
commit 1509a2a111
No known key found for this signature in database
GPG key ID: 0FDE7BE0E88F5E48

View file

@ -23,7 +23,7 @@
DEALINGS IN THE SOFTWARE.
</copyright>
<interface name="zxdg_decoration_manager_v1" version="1">
<interface name="zxdg_decoration_manager_v1" version="2">
<description summary="window decoration manager">
This interface allows a compositor to announce support for server-side
decorations.
@ -60,18 +60,33 @@
<description summary="create a new toplevel decoration object">
Create a new decoration object associated with the given toplevel.
Creating an xdg_toplevel_decoration from an xdg_toplevel which has a
buffer attached or committed is a client error, and any attempts by a
client to attach or manipulate a buffer prior to the first
xdg_toplevel_decoration.configure event must also be treated as
errors.
For objects of version 1, creating an xdg_toplevel_decoration from an
xdg_toplevel which has a buffer attached or committed is a client
error, and any attempts by a client to attach or manipulate a buffer
prior to the first xdg_toplevel_decoration.configure event must also be
treated as errors.
For objects of version 2 or newer, creating an xdg_toplevel_decoration
from an xdg_toplevel which has a buffer attached or committed is
allowed. The initial decoration mode of the surface if a buffer is
already attached depends on whether a xdg_toplevel_decoration object
has been associated with the surface or not prior to this request.
If an xdg_toplevel_decoration was associated with the surface, then
destroyed without a surface commit, the previous decoration mode is
retained.
If no xdg_toplevel_decoration was associated with the surface prior to
this request, or if a surface commit has been perfomed after a previous
xdg_toplevel_decoration object associated with the surface was
destroyed, the decoration mode is assumed to be client-side.
</description>
<arg name="id" type="new_id" interface="zxdg_toplevel_decoration_v1"/>
<arg name="toplevel" type="object" interface="xdg_toplevel"/>
</request>
</interface>
<interface name="zxdg_toplevel_decoration_v1" version="1">
<interface name="zxdg_toplevel_decoration_v1" version="2">
<description summary="decoration object for a toplevel surface">
The decoration object allows the compositor to toggle server-side window
decorations for a toplevel surface. The client can request to switch to
@ -93,7 +108,8 @@
<request name="destroy" type="destructor">
<description summary="destroy the decoration object">
Switch back to a mode without any server-side decorations at the next
commit.
commit, unless a new xdg_toplevel_decoration is created for the surface
first.
</description>
</request>