Hi, What about when clients change their "preference" in combination with a window state change?
Lets assume the compositor prefers server side, and the current state is that the client has set the preferred state to "server_side" as well. For client driven state change: client: unset_maximize server: configure(server_side, unmaximized) client: set_state(client_side) server: configure(client_side, unmaximized) And for the server driven state change: server: configure(server_side, unmaximized) client: set_state(client_side) server: configure(client_side, unmaximized) We'll temporarly have a unwanted configured state after the first configures. I guess this is work-around:able by requiring the compositor to always reply with a configure() event for each (un)set_state() request no matter whether any state changed or not (except for the initial state!), and require the client to always ignore the configure() event when it knows it will change its state preference. Requiring that is a bit awkward, or what do you think? It'll make an extra back-and-forth between the compositor and client a necessity when a decoration state preference depends on some other window state. I don't have a better alternative in mind though. Jonas On Mon, Jun 11, 2018 at 05:03:36AM -0400, Simon Ser wrote: > Hi Jonas, > > Any news about this? > > Thanks, > > --- > Simon Ser > https://emersion.fr > > On June 4, 2018 9:11 AM, Simon Ser <cont...@emersion.fr> wrote: > > Hi Jonas, > > > > Did you have the chance to have a look at this version? > > > > Thanks, > > --- > > Simon Ser > > https://emersion.fr > > > > On May 28, 2018 8:04 AM, Simon Ser <cont...@emersion.fr> wrote: > > > 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 > > _______________________________________________ > > 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
