Hi Jonas, What do you think of this new proposal?
Thanks, --- Simon Ser https://emersion.fr On May 20, 2018 11:39 AM, Simon Ser <cont...@emersion.fr> 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 <cont...@emersion.fr> > > [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 v5 to v6: > - Add back the set_mode request, add a new unset_mode request > > This version fixes the race condition Jonas pointed out in his v4 review. > > I believe there were two client use-cases for the set_mode request in v4: > - Request a specific preferred mode, and ignore the compositor preference. > This > is still possible since the set_mode request is back. > - Use the compositor's preference, as the client doesn't have one. In v4 this > was achieved by sending a set_mode request with the mode received in the > preferred_mode event. In this version this is achieved by not unsetting the > mode (either by not sending any set_mode request, or by sending an > unset_mode > request). > > The race condition could happen in v4 if the compositor sent a preferred_mode > event and couldn't decide if the client would want to keep its current mode or > change it (ie. should the compositor wait for a set_mode request or not?). > This > new design doesn't let the client know the compositor's preferred mode. When > the > compositor changes its preferred mode, it already knows if the client prefers > to > use it or to use its own - and thus can directly send a configure event if > necessary. > > I believe this lso simplifies the protocol and makes it easier to understand. > I > don't think there are any regressions due to the fact that the client doesn't > know anymore the compositor's preferred mode. > > [1] https://github.com/swaywm/wlroots/pull/638 > > Makefile.am | 1 + > unstable/xdg-decoration/README | 4 + > .../xdg-decoration-unstable-v1.xml | 145 ++++++++++++++++++ > 3 files changed, 150 insertions(+) > create mode 100644 unstable/xdg-decoration/README > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 4b9a901..71909d8 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-decoration/xdg-decoration-unstable-v1.xml \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README > new file mode 100644 > index 0000000..73f0c52 > --- /dev/null > +++ b/unstable/xdg-decoration/README > @@ -0,0 +1,4 @@ > +xdg_decoration protocol > + > +Maintainers: > +Simon Ser <cont...@emersion.fr> > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > new file mode 100644 > index 0000000..cf8cbdb > --- /dev/null > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > @@ -0,0 +1,145 @@ > +<?xml version="1.0" encoding="UTF-8"?> > +<protocol name="xdg_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_decoration_manager_v1" version="1"> > + <description summary="window decoration manager"> > + This interface allows a compositor to announce support for server-side > + decorations. > + > + 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_toplevel_decoration"> > + <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 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 window > 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. This informs the compositor > + that the client prefers the provided 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> > + > + <request name="unset_mode"> > + <description summary="unset the decoration mode"> > + Unset the toplevel surface decoration mode. This informs the > compositor > + that the client doesn't prefer a particular decoration mode. > + > + After unsetting 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). > + </description> > + </request> > + > + <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. Clients must > send an > + ack_configure in response to this event. See xdg_surface.configure > and > + xdg_surface.ack_configure for details. > + > + A configure event can be sent at any time. 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.17.0 > > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel