[PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol
Jonas Ådahl
jadahl at gmail.com
Fri Apr 13 13:56:37 UTC 2018
On Sat, Mar 24, 2018 at 07:08:15AM -0400, Simon Ser wrote:
> This adds a new protocol to negotiate server-side rendering of window
> decorations for xdg-toplevels. This allows compositors that want to draw
> decorations themselves to send their preference to clients, and clients that
> prefer server-side decorations to request them.
>
> This is inspired by a protocol from KDE [1] which has been implemented in
> KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> provides an updated protocol with those concerns taken into account.
>
> Signed-off-by: Simon Ser <contact at emersion.fr>
> Reviewed-by: Drew DeVault <sir at cmpwn.com>
> Reviewed-by: David Edmundson <david at davidedmundson.co.uk>
> Reviewed-by: Alan Griffiths <alan.griffiths at canonical.com>
> Reviewed-by: Tony Crisci <tony at dubstepdish.com>
>
> [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> ---
>
> This was iterated on privately between representatives of Sway and wlroots
> (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
> Mir (Alan Griffiths).
>
> A proof-of-concept of a client and server implementation is available at [1].
>
> Changes from v3 to v4:
> - Updated the definition of decorations to remove unnecessary constraints (Eike)
> - Fix ambiguity in zxdg_toplevel_decoration_v1 description (Peter)
> - Specify that the decoration object must be destroyed before the toplevel
> (Pekka, Peter)
> - Changed decoration mode enum to "client_side" and "server_side" (Peter)
> - Replaced "server" with "compositor" in preferred_mode event description
> (Peter)
> - State that the mode sent by the compositor with the configure event must be
> obeyed (Peter)
> - Reword client-side decorations description (Eike)
Hi,
I have some questions about some of the details.
What is the purpose of making the compositor changing the "preferred"
mode? If we would make the assumption that a compositor stays the same
during the whole session as in it'll either always prefer or not prefer
dealing with decorations, and we assume that we always only have the two
"modes", the protocol could probably be greatly simplified by just
having a destroy function, and assuming a client having created the
decoration object always outsourcing the drawing decorations etc to the
compositor.
If there is some reason that it actually should be changeable, or that
more modes may be added later, I think there are two problems:
If we add more modes, compositor or clients are forced to support all
different combinations of modes to support new versions of the protocol.
This could be solveable by doing two changes:
1) Make "preferred_mode" an ordered array with supported modes in the
order of preference. 2) Don't let the compositor ignore the set_mode()
request. That way, the compositor will let the client know what it can
do and how it prefers things, and the client can safely make a decision
it knows it can support. With this, I don't think we'd need the
configure event anymore as well, we'd just assume the "set_mode" request
to be part of the wl_surface transaction.
Another thing to consider is whether non-toplevels ever want a similar
kind of protocol? It is not something we need to go into much further
details now, but it would be easy to add into this protocol by just
renaming the directory under unstable/ and the XML file to
"xdg-decorations" or something. Would we have another type of surface
that needs similar functionality, we could add that as a separate pair
of interfaces.
Jonas
>
> [1] https://github.com/swaywm/wlroots/pull/638
>
> Makefile.am | 1 +
> unstable/xdg-toplevel-decoration/README | 4 +
> .../xdg-toplevel-decoration-unstable-v1.xml | 139 +++++++++++++++++++++
> 3 files changed, 144 insertions(+)
> create mode 100644 unstable/xdg-toplevel-decoration/README
> create mode 100644 unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..07744e9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -17,6 +17,7 @@ unstable_protocols = \
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
> unstable/xdg-output/xdg-output-unstable-v1.xml \
> unstable/input-timestamps/input-timestamps-unstable-v1.xml \
> + unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml \
> $(NULL)
>
> stable_protocols = \
> diff --git a/unstable/xdg-toplevel-decoration/README b/unstable/xdg-toplevel-decoration/README
> new file mode 100644
> index 0000000..e927110
> --- /dev/null
> +++ b/unstable/xdg-toplevel-decoration/README
> @@ -0,0 +1,4 @@
> +xdg_toplevel_decoration protocol
> +
> +Maintainers:
> +Simon Ser <contact at emersion.fr>
> diff --git a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> new file mode 100644
> index 0000000..8fbc688
> --- /dev/null
> +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> @@ -0,0 +1,139 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="xdg_toplevel_decoration_unstable_v1">
> + <copyright>
> + Copyright © 2018 Simon Ser
> +
> + Permission is hereby granted, free of charge, to any person obtaining a
> + copy of this software and associated documentation files (the "Software"),
> + to deal in the Software without restriction, including without limitation
> + the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + and/or sell copies of the Software, and to permit persons to whom the
> + Software is furnished to do so, subject to the following conditions:
> +
> + The above copyright notice and this permission notice (including the next
> + paragraph) shall be included in all copies or substantial portions of the
> + Software.
> +
> + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + DEALINGS IN THE SOFTWARE.
> + </copyright>
> +
> + <interface name="zxdg_toplevel_decoration_manager_v1" version="1">
> + <description summary="window decoration manager">
> + This interface allows a compositor to announce support for server-side
> + decorations and optionally express a preference for using them.
> +
> + A window decoration is a set of window controls as deemed appropriate by
> + the party managing them, such as user interface components used to move,
> + resize and change a window's state.
> +
> + A client can use this protocol to request being decorated by a supporting
> + compositor.
> +
> + If compositor and client do not negotiate the use of a server-side
> + decoration using this protocol, clients continue to self-decorate as they
> + see fit.
> +
> + Warning! The protocol described in this file is experimental and
> + backward incompatible changes may be made. Backward compatible changes
> + may be added together with the corresponding interface version bump.
> + Backward incompatible changes are done by bumping the version number in
> + the protocol and interface names and resetting the interface version.
> + Once the protocol is to be declared stable, the 'z' prefix and the
> + version number in the protocol and interface names are removed and the
> + interface version number is reset.
> + </description>
> +
> + <enum name="error">
> + <entry name="unconfigured_buffer" value="1"/>
> + <entry name="already_constructed" value="2"/>
> + </enum>
> +
> + <request name="destroy" type="destructor">
> + <description summary="destroy the decoration manager object">
> + Destroy the decoration manager.
> + </description>
> + </request>
> +
> + <request name="get_decoration">
> + <description summary="create a new 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 call must also be treated as
> + errors.
> + </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">
> + <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
> + another mode.
> +
> + The xdg_toplevel_decoration object must be destroyed before its
> + xdg_toplevel.
> + </description>
> +
> + <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.
> + </description>
> + </request>
> +
> + <enum name="mode">
> + <description summary="window decoration modes">
> + These values describe window decoration modes.
> + </description>
> + <entry name="client_side" value="1" summary="no server-side decoration"/>
> + <entry name="server_side" value="2" summary="server-side window decoration"/>
> + </enum>
> +
> + <request name="set_mode">
> + <description summary="set the decoration mode">
> + Set the toplevel surface decoration mode.
> +
> + After requesting a decoration mode, the compositor will respond by
> + emitting a xdg_surface.configure event. The client should then update
> + its content, drawing it without decorations if the received mode is
> + server-side decorations. The client must also acknowledge the configure
> + when committing the new content (see xdg_surface.ack_configure).
> +
> + The compositor can ignore this request.
> + </description>
> + <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
> + </request>
> +
> + <event name="preferred_mode">
> + <description summary="advertise the compositor's preferred mode">
> + The preferred_mode event describes the compositor's preferred decoration
> + mode for this toplevel surface. The event is sent when binding to the
> + decoration object and whenever the preferred mode changes.
> + </description>
> + <arg name="mode" type="uint" enum="mode" summary="the preferred mode"/>
> + </event>
> +
> + <event name="configure">
> + <description summary="suggest a surface change">
> + The configure event asks the client to change its decoration mode. The
> + configured state should not be applied immediately. See
> + xdg_surface.configure for details.
> +
> + A configure event can be sent at any time, not necessarily in reply to a
> + set_mode request. The specified mode must be obeyed by the client.
> + </description>
> + <arg name="mode" type="uint" enum="mode" summary="the decoration mode"/>
> + </event>
> + </interface>
> +</protocol>
> --
> 2.16.2
>
>
More information about the wayland-devel
mailing list