Add layer-shell-unstable-v1.xml

Submitted by Drew DeVault on May 8, 2018, 12:48 a.m.

Details

Message ID 20180508004825.28413-1-sir@cmpwn.com
State Superseded
Headers show
Series "Add layer-shell-unstable-v1.xml" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Drew DeVault May 8, 2018, 12:48 a.m.
The layer-shell introduces the concept of desktop "layers", each of
which has a collection of surfaces. The layer shell affords its clients
some freedom over how their surfaces are arranged with respect to each
other and the available space on the output.

The goal of this shell is to allow end-users and compositor authors to
write desktop components and extensions which are portable across
compositors. Use-cases include wallpapers, panels/taskbars, lock
screens, notification daemons, etc; which will work correctly on any
compositor which implements this protocol.
---
This underwent a pretty grueling review process on our own team over at
wlroots. A review of this discussion may answer some of the questions
you have:

https://github.com/swaywm/wlr-protocols/pull/7

An earlier version of this protocol (the only difference being zwlr_*
rather than zxdg_*) is implemented in several compositors and clients.
Here's all of the implementations I'm aware of...

wlroots has a complete implementation:

https://github.com/swaywm/wlroots/blob/master/types/wlr_layer_shell.c
https://github.com/swaywm/wlroots/blob/master/rootston/layer_shell.c

Sway has a mostly complete implementation (missing popups):

https://github.com/swaywm/sway/blob/master/sway/desktop/layer_shell.c

waymonad has a WIP implementation:

https://github.com/waymonad/waymonad/tree/surface-layers

Way Cooler intends to implement it:

https://github.com/way-cooler/way-cooler/issues/514

I also sat down with the KDE folks and they seem to like it and are
considering implementing it. There are also several clients that support
it. wlroots contains an example client implementing all features with
useful getopt flags for testing:

https://github.com/swaywm/wlroots/blob/master/examples/layer-shell.c

Sway's swaybar, swaybg, and swaylock use it:

https://github.com/swaywm/sway/tree/master/swaybar
https://github.com/swaywm/sway/tree/master/swaybg
https://github.com/swaywm/sway/tree/master/swaybg

A notification daemon, mako, uses it:

https://github.com/emersion/mako

A launcher, bemenu, uses it:

https://github.com/cloudef/bemenu

The Librem5 (phone) shell has been ported to it as well:

https://code.puri.sm/Librem5/phosh

I also made a Qt implementation, which I expect the KDE folks will use:

https://github.com/SirCmpwn/qtlayershell

The benefit of all of these implementations is that we've already spent
a fair bit of time perfecting and proving this protocol's utility and
design. However, everyone is prepared to make changes as the protocol
evolves on the mailing list.

 .../layer-shell/layer-shell-unstable-v1.xml   | 285 ++++++++++++++++++
 1 file changed, 285 insertions(+)
 create mode 100644 unstable/layer-shell/layer-shell-unstable-v1.xml

Patch hide | download patch | download mbox

diff --git a/unstable/layer-shell/layer-shell-unstable-v1.xml b/unstable/layer-shell/layer-shell-unstable-v1.xml
new file mode 100644
index 0000000..41fb685
--- /dev/null
+++ b/unstable/layer-shell/layer-shell-unstable-v1.xml
@@ -0,0 +1,285 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="xdg_layer_shell_unstable_v1">
+  <copyright>
+    Copyright © 2018 Drew DeVault
+
+    Permission to use, copy, modify, distribute, and sell this
+    software and its documentation for any purpose is hereby granted
+    without fee, provided that the above copyright notice appear in
+    all copies and that both that copyright notice and this permission
+    notice appear in supporting documentation, and that the name of
+    the copyright holders not be used in advertising or publicity
+    pertaining to distribution of the software without specific,
+    written prior permission.  The copyright holders make no
+    representations about the suitability of this software for any
+    purpose.  It is provided "as is" without express or implied
+    warranty.
+
+    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+    THIS SOFTWARE.
+  </copyright>
+
+  <interface name="zxdg_layer_shell_v1" version="1">
+    <description summary="create surfaces that are layers of the desktop">
+      Clients can use this interface to assign the surface_layer role to
+      wl_surfaces. Such surfaces are assigned to a "layer" of the output and
+      rendered with a defined z-depth respective to each other. They may also be
+      anchored to the edges and corners of a screen and specify input handling
+      semantics. This interface should be suitable for the implementation of
+      many desktop shell components, and a broad number of other applications
+      that interact with the desktop.
+    </description>
+
+    <request name="get_layer_surface">
+      <description summary="create a layer_surface from a surface">
+        Create a layer surface for an existing surface. This assigns the role of
+        layer_surface, or raises a protocol error if another role is already
+        assigned.
+
+        Creating a layer surface from a wl_surface 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 layer_surface.configure call
+        must also be treated as errors.
+
+        You may pass NULL for output to allow the compositor to decide which
+        output to use. Generally this will be the one that the user most
+        recently interacted with.
+
+        Clients can specify a namespace that defines the purpose of the layer
+        surface.
+      </description>
+      <arg name="id" type="new_id" interface="zxdg_layer_surface_v1"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
+      <arg name="layer" type="uint" enum="layer" summary="layer to add this surface to"/>
+      <arg name="namespace" type="string" summary="namespace for the layer surface"/>
+    </request>
+
+    <enum name="error">
+      <entry name="role" value="0" summary="wl_surface has another role"/>
+      <entry name="invalid_layer" value="1" summary="layer value is invalid"/>
+      <entry name="already_constructed" value="2" summary="wl_surface has a buffer attached or committed"/>
+    </enum>
+
+    <enum name="layer">
+      <description summary="available layers for surfaces">
+        These values indicate which layers a surface can be rendered in. They
+        are ordered by z depth, bottom-most first. Traditional shell surfaces
+        will typically be rendered between the bottom and top layers.
+        Fullscreen shell surfaces are typically rendered at the top layer.
+        Multiple surfaces can share a single layer, and ordering within a
+        single layer is undefined.
+      </description>
+
+      <entry name="background" value="0"/>
+      <entry name="bottom" value="1"/>
+      <entry name="top" value="2"/>
+      <entry name="overlay" value="3"/>
+    </enum>
+  </interface>
+
+  <interface name="zxdg_layer_surface_v1" version="1">
+    <description summary="layer metadata interface">
+      An interface that may be implemented by a wl_surface, for surfaces that
+      are designed to be rendered as a layer of a stacked desktop-like
+      environment.
+
+      Layer surface state (size, anchor, exclusive zone, margin, interactivity)
+      is double-buffered, and will be applied at the time wl_surface.commit of
+      the corresponding wl_surface is called.
+    </description>
+
+    <request name="set_size">
+      <description summary="sets the size of the surface">
+        Sets the size of the surface in surface-local coordinates. The
+        compositor will display the surface centered with respect to its
+        anchors.
+
+        If you pass 0 for either value, the compositor will assign it and
+        inform you of the assignment in the configure event. You must set your
+        anchor to opposite edges in the dimensions you omit; not doing so is a
+        protocol error. Both values are 0 by default.
+
+        Size is double-buffered, see wl_surface.commit.
+      </description>
+      <arg name="width" type="uint"/>
+      <arg name="height" type="uint"/>
+    </request>
+
+    <request name="set_anchor">
+      <description summary="configures the anchor point of the surface">
+        Requests that the compositor anchor the surface to the specified edges
+        and corners. If two orthoginal edges are specified (e.g. 'top' and
+        'left'), then the anchor point will be the intersection of the edges
+        (e.g. the top left corner of the output); otherwise the anchor point
+        will be centered on that edge, or in the center if none is specified.
+
+        Anchor is double-buffered, see wl_surface.commit.
+      </description>
+      <arg name="anchor" type="uint" enum="anchor"/>
+    </request>
+
+    <request name="set_exclusive_zone">
+      <description summary="configures the exclusive geometry of this surface">
+        Requests that the compositor avoids occluding an area of the surface
+        with other surfaces. The compositor's use of this information is
+        implementation-dependent - do not assume that this region will not
+        actually be occluded.
+
+        A positive value is only meaningful if the surface is anchored to an
+        edge, rather than a corner. The zone is the number of surface-local
+        coordinates from the edge that are considered exclusive.
+
+        Surfaces that do not wish to have an exclusive zone may instead specify
+        how they should interact with surfaces that do. If set to zero, the
+        surface indicates that it would like to be moved to avoid occluding
+        surfaces with a positive excluzive zone. If set to -1, the surface
+        indicates that it would not like to be moved to accomodate for other
+        surfaces, and the compositor should extend it all the way to the edges
+        it is anchored to.
+
+        For example, a panel might set its exclusive zone to 10, so that
+        maximized shell surfaces are not shown on top of it. A notification
+        might set its exclusive zone to 0, so that it is moved to avoid
+        occluding the panel, but shell surfaces are shown underneath it. A
+        wallpaper or lock screen might set their exclusive zone to -1, so that
+        they stretch below or over the panel.
+
+        The default value is 0.
+
+        Exclusive zone is double-buffered, see wl_surface.commit.
+      </description>
+      <arg name="zone" type="int"/>
+    </request>
+
+    <request name="set_margin">
+      <description summary="sets a margin from the anchor point">
+        Requests that the surface be placed some distance away from the anchor
+        point on the output, in surface-local coordinates. Setting this value
+        for edges you are not anchored to has no effect.
+
+        The exclusive zone includes the margin.
+
+        Margin is double-buffered, see wl_surface.commit.
+      </description>
+      <arg name="top" type="int"/>
+      <arg name="right" type="int"/>
+      <arg name="bottom" type="int"/>
+      <arg name="left" type="int"/>
+    </request>
+
+    <request name="set_keyboard_interactivity">
+      <description summary="requests keyboard events">
+        Set to 1 to request that the seat send keyboard events to this layer
+        surface. For layers below the shell surface layer, the seat will use
+        normal focus semantics. For layers above the shell surface layers, the
+        seat will always give exclusive keyboard focus to the top-most layer
+        which has keyboard interactivity set to true.
+
+        Layer surfaces receive pointer, touch, and tablet events normally. If
+        you do not want to receive them, set the input region on your surface
+        to an empty region.
+
+        Events is double-buffered, see wl_surface.commit.
+      </description>
+      <arg name="keyboard_interactivity" type="uint"/>
+    </request>
+
+    <request name="get_popup">
+      <description summary="assign this layer_surface as an xdg_popup parent">
+        This assigns an xdg_popup's parent to this layer_surface.  This popup
+        should have been created via xdg_surface::get_popup with the parent set
+        to NULL, and this request must be invoked before committing the popup's
+        initial state.
+
+        See the documentation of xdg_popup for more details about what an
+        xdg_popup is and how it is used.
+      </description>
+      <arg name="popup" type="object" interface="xdg_popup"/>
+    </request>
+
+    <request name="ack_configure">
+      <description summary="ack a configure event">
+        When a configure event is received, if a client commits the
+        surface in response to the configure event, then the client
+        must make an ack_configure request sometime before the commit
+        request, passing along the serial of the configure event.
+
+        If the client receives multiple configure events before it
+        can respond to one, it only has to ack the last configure event.
+
+        A client is not required to commit immediately after sending
+        an ack_configure request - it may even ack_configure several times
+        before its next surface commit.
+
+        A client may send multiple ack_configure requests before committing, but
+        only the last request sent before a commit indicates which configure
+        event the client really is responding to.
+      </description>
+      <arg name="serial" type="uint" summary="the serial from the configure event"/>
+    </request>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the layer_surface">
+        This request destroys the layer surface.
+      </description>
+    </request>
+
+    <event name="configure">
+      <description summary="suggest a surface change">
+        The configure event asks the client to resize its surface.
+
+        Clients should arrange their surface for the new states, and then send
+        an ack_configure request with the serial sent in this configure event at
+        some point before committing the new surface.
+
+        The client is free to dismiss all but the last configure event it
+        received.
+
+        The width and height arguments specify the size of the window in
+        surface-local coordinates.
+
+        The size is a hint, in the sense that the client is free to ignore it if
+        it doesn't resize, pick a smaller size (to satisfy aspect ratio or
+        resize in steps of NxM pixels). If the client picks a smaller size and
+        is anchored to two opposite anchors (e.g. 'top' and 'bottom'), the
+        surface will be centered on this axis.
+
+        If the width or height arguments are zero, it means the client should
+        decide its own window dimension.
+      </description>
+      <arg name="serial" type="uint"/>
+      <arg name="width" type="uint"/>
+      <arg name="height" type="uint"/>
+    </event>
+
+    <event name="closed">
+      <description summary="surface should be closed">
+        The closed event is sent by the compositor when the surface will no
+        longer be shown. The output may have been destroyed or the user may
+        have asked for it to be removed. Further changes to the surface will be
+        ignored. The client should destroy the resource after receiving this
+        event, and create a new surface if they so choose.
+      </description>
+    </event>
+
+    <enum name="error">
+      <entry name="invalid_surface_state" value="0" summary="provided surface state is invalid"/>
+      <entry name="invalid_size" value="1" summary="size is invalid"/>
+      <entry name="invalid_anchor" value="2" summary="anchor bitfield is invalid"/>
+    </enum>
+
+    <enum name="anchor" bitfield="true">
+      <entry name="top" value="1" summary="the top edge of the anchor rectangle"/>
+      <entry name="bottom" value="2" summary="the bottom edge of the anchor rectangle"/>
+      <entry name="left" value="4" summary="the left edge of the anchor rectangle"/>
+      <entry name="right" value="8" summary="the right edge of the anchor rectangle"/>
+    </enum>
+  </interface>
+</protocol>

Comments

Hi,

So the purpose here is to provide a way to allow constructing a desktop
environment by combining different components more or less arbitrarily.
I also assume this is a newer version of the one proposed
earlier[0][1][2]. As was said before, it has been a non-goal for
wayland-protocols to provide such interfaces. It has been so for mainly
two reasons:

1) The protocols distributed should be seen as functionality a client
can potentially expect from any compositor. Of course some functionality
might be missing from various compositors, and a client may require a
missing functionality to function properly (for example drawing
application specializing in drawing tablets requires the drawing tablet
protocol), but it is less likely a non-goal for a compositor to support
for example a drawing tablet. Sometimes a client can also have fallbacks
when a compositor misses some functionality, for example if
wp_viewporter is missing, a client can clip and resize client side.

2) Things for constructing and/or configuring a desktop environment will
often need to be privileged, which is not something we handle currently.
This is a reason we have always avoided anything similar to a
"wl_randr", and I expect panels and similar things have similar
complications and requirements.

It is my opinion that we should continue with the scope described above,
to make a clear separation between what portable clients can expect
while expecting to work both on highly integrated environments and less
integrated environments alike.

With all this being said, this obviously doesn't mean one can not make a
Wayland DE out of a multitude of third party components; wayland (the
repository and tarball) and wayland-protocols are not the only way to
distribute protocols. There is already wayland-wall[3] which aims to
cover the use case for building a desktop environment by combining
different components, and there is no reason why we can't have more
sources (maybe a future test suite for example?).


Jonas

[0] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032520.html
[1] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032567.html
[2] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032825.html
[3] https://github.com/wayland-wall

On Mon, May 07, 2018 at 08:48:25PM -0400, Drew DeVault wrote:
> The layer-shell introduces the concept of desktop "layers", each of
> which has a collection of surfaces. The layer shell affords its clients
> some freedom over how their surfaces are arranged with respect to each
> other and the available space on the output.
> 
> The goal of this shell is to allow end-users and compositor authors to
> write desktop components and extensions which are portable across
> compositors. Use-cases include wallpapers, panels/taskbars, lock
> screens, notification daemons, etc; which will work correctly on any
> compositor which implements this protocol.
> ---
> This underwent a pretty grueling review process on our own team over at
> wlroots. A review of this discussion may answer some of the questions
> you have:
> 
> https://github.com/swaywm/wlr-protocols/pull/7
> 
> An earlier version of this protocol (the only difference being zwlr_*
> rather than zxdg_*) is implemented in several compositors and clients.
> Here's all of the implementations I'm aware of...
> 
> wlroots has a complete implementation:
> 
> https://github.com/swaywm/wlroots/blob/master/types/wlr_layer_shell.c
> https://github.com/swaywm/wlroots/blob/master/rootston/layer_shell.c
> 
> Sway has a mostly complete implementation (missing popups):
> 
> https://github.com/swaywm/sway/blob/master/sway/desktop/layer_shell.c
> 
> waymonad has a WIP implementation:
> 
> https://github.com/waymonad/waymonad/tree/surface-layers
> 
> Way Cooler intends to implement it:
> 
> https://github.com/way-cooler/way-cooler/issues/514
> 
> I also sat down with the KDE folks and they seem to like it and are
> considering implementing it. There are also several clients that support
> it. wlroots contains an example client implementing all features with
> useful getopt flags for testing:
> 
> https://github.com/swaywm/wlroots/blob/master/examples/layer-shell.c
> 
> Sway's swaybar, swaybg, and swaylock use it:
> 
> https://github.com/swaywm/sway/tree/master/swaybar
> https://github.com/swaywm/sway/tree/master/swaybg
> https://github.com/swaywm/sway/tree/master/swaybg
> 
> A notification daemon, mako, uses it:
> 
> https://github.com/emersion/mako
> 
> A launcher, bemenu, uses it:
> 
> https://github.com/cloudef/bemenu
> 
> The Librem5 (phone) shell has been ported to it as well:
> 
> https://code.puri.sm/Librem5/phosh
> 
> I also made a Qt implementation, which I expect the KDE folks will use:
> 
> https://github.com/SirCmpwn/qtlayershell
> 
> The benefit of all of these implementations is that we've already spent
> a fair bit of time perfecting and proving this protocol's utility and
> design. However, everyone is prepared to make changes as the protocol
> evolves on the mailing list.
> 
>  .../layer-shell/layer-shell-unstable-v1.xml   | 285 ++++++++++++++++++
>  1 file changed, 285 insertions(+)
>  create mode 100644 unstable/layer-shell/layer-shell-unstable-v1.xml
> 
> diff --git a/unstable/layer-shell/layer-shell-unstable-v1.xml b/unstable/layer-shell/layer-shell-unstable-v1.xml
> new file mode 100644
> index 0000000..41fb685
> --- /dev/null
> +++ b/unstable/layer-shell/layer-shell-unstable-v1.xml
> @@ -0,0 +1,285 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="xdg_layer_shell_unstable_v1">
> +  <copyright>
> +    Copyright © 2018 Drew DeVault
> +
> +    Permission to use, copy, modify, distribute, and sell this
> +    software and its documentation for any purpose is hereby granted
> +    without fee, provided that the above copyright notice appear in
> +    all copies and that both that copyright notice and this permission
> +    notice appear in supporting documentation, and that the name of
> +    the copyright holders not be used in advertising or publicity
> +    pertaining to distribution of the software without specific,
> +    written prior permission.  The copyright holders make no
> +    representations about the suitability of this software for any
> +    purpose.  It is provided "as is" without express or implied
> +    warranty.
> +
> +    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> +    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> +    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> +    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> +    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> +    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> +    THIS SOFTWARE.
> +  </copyright>
> +
> +  <interface name="zxdg_layer_shell_v1" version="1">
> +    <description summary="create surfaces that are layers of the desktop">
> +      Clients can use this interface to assign the surface_layer role to
> +      wl_surfaces. Such surfaces are assigned to a "layer" of the output and
> +      rendered with a defined z-depth respective to each other. They may also be
> +      anchored to the edges and corners of a screen and specify input handling
> +      semantics. This interface should be suitable for the implementation of
> +      many desktop shell components, and a broad number of other applications
> +      that interact with the desktop.
> +    </description>
> +
> +    <request name="get_layer_surface">
> +      <description summary="create a layer_surface from a surface">
> +        Create a layer surface for an existing surface. This assigns the role of
> +        layer_surface, or raises a protocol error if another role is already
> +        assigned.
> +
> +        Creating a layer surface from a wl_surface 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 layer_surface.configure call
> +        must also be treated as errors.
> +
> +        You may pass NULL for output to allow the compositor to decide which
> +        output to use. Generally this will be the one that the user most
> +        recently interacted with.
> +
> +        Clients can specify a namespace that defines the purpose of the layer
> +        surface.
> +      </description>
> +      <arg name="id" type="new_id" interface="zxdg_layer_surface_v1"/>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
> +      <arg name="layer" type="uint" enum="layer" summary="layer to add this surface to"/>
> +      <arg name="namespace" type="string" summary="namespace for the layer surface"/>
> +    </request>
> +
> +    <enum name="error">
> +      <entry name="role" value="0" summary="wl_surface has another role"/>
> +      <entry name="invalid_layer" value="1" summary="layer value is invalid"/>
> +      <entry name="already_constructed" value="2" summary="wl_surface has a buffer attached or committed"/>
> +    </enum>
> +
> +    <enum name="layer">
> +      <description summary="available layers for surfaces">
> +        These values indicate which layers a surface can be rendered in. They
> +        are ordered by z depth, bottom-most first. Traditional shell surfaces
> +        will typically be rendered between the bottom and top layers.
> +        Fullscreen shell surfaces are typically rendered at the top layer.
> +        Multiple surfaces can share a single layer, and ordering within a
> +        single layer is undefined.
> +      </description>
> +
> +      <entry name="background" value="0"/>
> +      <entry name="bottom" value="1"/>
> +      <entry name="top" value="2"/>
> +      <entry name="overlay" value="3"/>
> +    </enum>
> +  </interface>
> +
> +  <interface name="zxdg_layer_surface_v1" version="1">
> +    <description summary="layer metadata interface">
> +      An interface that may be implemented by a wl_surface, for surfaces that
> +      are designed to be rendered as a layer of a stacked desktop-like
> +      environment.
> +
> +      Layer surface state (size, anchor, exclusive zone, margin, interactivity)
> +      is double-buffered, and will be applied at the time wl_surface.commit of
> +      the corresponding wl_surface is called.
> +    </description>
> +
> +    <request name="set_size">
> +      <description summary="sets the size of the surface">
> +        Sets the size of the surface in surface-local coordinates. The
> +        compositor will display the surface centered with respect to its
> +        anchors.
> +
> +        If you pass 0 for either value, the compositor will assign it and
> +        inform you of the assignment in the configure event. You must set your
> +        anchor to opposite edges in the dimensions you omit; not doing so is a
> +        protocol error. Both values are 0 by default.
> +
> +        Size is double-buffered, see wl_surface.commit.
> +      </description>
> +      <arg name="width" type="uint"/>
> +      <arg name="height" type="uint"/>
> +    </request>
> +
> +    <request name="set_anchor">
> +      <description summary="configures the anchor point of the surface">
> +        Requests that the compositor anchor the surface to the specified edges
> +        and corners. If two orthoginal edges are specified (e.g. 'top' and
> +        'left'), then the anchor point will be the intersection of the edges
> +        (e.g. the top left corner of the output); otherwise the anchor point
> +        will be centered on that edge, or in the center if none is specified.
> +
> +        Anchor is double-buffered, see wl_surface.commit.
> +      </description>
> +      <arg name="anchor" type="uint" enum="anchor"/>
> +    </request>
> +
> +    <request name="set_exclusive_zone">
> +      <description summary="configures the exclusive geometry of this surface">
> +        Requests that the compositor avoids occluding an area of the surface
> +        with other surfaces. The compositor's use of this information is
> +        implementation-dependent - do not assume that this region will not
> +        actually be occluded.
> +
> +        A positive value is only meaningful if the surface is anchored to an
> +        edge, rather than a corner. The zone is the number of surface-local
> +        coordinates from the edge that are considered exclusive.
> +
> +        Surfaces that do not wish to have an exclusive zone may instead specify
> +        how they should interact with surfaces that do. If set to zero, the
> +        surface indicates that it would like to be moved to avoid occluding
> +        surfaces with a positive excluzive zone. If set to -1, the surface
> +        indicates that it would not like to be moved to accomodate for other
> +        surfaces, and the compositor should extend it all the way to the edges
> +        it is anchored to.
> +
> +        For example, a panel might set its exclusive zone to 10, so that
> +        maximized shell surfaces are not shown on top of it. A notification
> +        might set its exclusive zone to 0, so that it is moved to avoid
> +        occluding the panel, but shell surfaces are shown underneath it. A
> +        wallpaper or lock screen might set their exclusive zone to -1, so that
> +        they stretch below or over the panel.
> +
> +        The default value is 0.
> +
> +        Exclusive zone is double-buffered, see wl_surface.commit.
> +      </description>
> +      <arg name="zone" type="int"/>
> +    </request>
> +
> +    <request name="set_margin">
> +      <description summary="sets a margin from the anchor point">
> +        Requests that the surface be placed some distance away from the anchor
> +        point on the output, in surface-local coordinates. Setting this value
> +        for edges you are not anchored to has no effect.
> +
> +        The exclusive zone includes the margin.
> +
> +        Margin is double-buffered, see wl_surface.commit.
> +      </description>
> +      <arg name="top" type="int"/>
> +      <arg name="right" type="int"/>
> +      <arg name="bottom" type="int"/>
> +      <arg name="left" type="int"/>
> +    </request>
> +
> +    <request name="set_keyboard_interactivity">
> +      <description summary="requests keyboard events">
> +        Set to 1 to request that the seat send keyboard events to this layer
> +        surface. For layers below the shell surface layer, the seat will use
> +        normal focus semantics. For layers above the shell surface layers, the
> +        seat will always give exclusive keyboard focus to the top-most layer
> +        which has keyboard interactivity set to true.
> +
> +        Layer surfaces receive pointer, touch, and tablet events normally. If
> +        you do not want to receive them, set the input region on your surface
> +        to an empty region.
> +
> +        Events is double-buffered, see wl_surface.commit.
> +      </description>
> +      <arg name="keyboard_interactivity" type="uint"/>
> +    </request>
> +
> +    <request name="get_popup">
> +      <description summary="assign this layer_surface as an xdg_popup parent">
> +        This assigns an xdg_popup's parent to this layer_surface.  This popup
> +        should have been created via xdg_surface::get_popup with the parent set
> +        to NULL, and this request must be invoked before committing the popup's
> +        initial state.
> +
> +        See the documentation of xdg_popup for more details about what an
> +        xdg_popup is and how it is used.
> +      </description>
> +      <arg name="popup" type="object" interface="xdg_popup"/>
> +    </request>
> +
> +    <request name="ack_configure">
> +      <description summary="ack a configure event">
> +        When a configure event is received, if a client commits the
> +        surface in response to the configure event, then the client
> +        must make an ack_configure request sometime before the commit
> +        request, passing along the serial of the configure event.
> +
> +        If the client receives multiple configure events before it
> +        can respond to one, it only has to ack the last configure event.
> +
> +        A client is not required to commit immediately after sending
> +        an ack_configure request - it may even ack_configure several times
> +        before its next surface commit.
> +
> +        A client may send multiple ack_configure requests before committing, but
> +        only the last request sent before a commit indicates which configure
> +        event the client really is responding to.
> +      </description>
> +      <arg name="serial" type="uint" summary="the serial from the configure event"/>
> +    </request>
> +
> +    <request name="destroy" type="destructor">
> +      <description summary="destroy the layer_surface">
> +        This request destroys the layer surface.
> +      </description>
> +    </request>
> +
> +    <event name="configure">
> +      <description summary="suggest a surface change">
> +        The configure event asks the client to resize its surface.
> +
> +        Clients should arrange their surface for the new states, and then send
> +        an ack_configure request with the serial sent in this configure event at
> +        some point before committing the new surface.
> +
> +        The client is free to dismiss all but the last configure event it
> +        received.
> +
> +        The width and height arguments specify the size of the window in
> +        surface-local coordinates.
> +
> +        The size is a hint, in the sense that the client is free to ignore it if
> +        it doesn't resize, pick a smaller size (to satisfy aspect ratio or
> +        resize in steps of NxM pixels). If the client picks a smaller size and
> +        is anchored to two opposite anchors (e.g. 'top' and 'bottom'), the
> +        surface will be centered on this axis.
> +
> +        If the width or height arguments are zero, it means the client should
> +        decide its own window dimension.
> +      </description>
> +      <arg name="serial" type="uint"/>
> +      <arg name="width" type="uint"/>
> +      <arg name="height" type="uint"/>
> +    </event>
> +
> +    <event name="closed">
> +      <description summary="surface should be closed">
> +        The closed event is sent by the compositor when the surface will no
> +        longer be shown. The output may have been destroyed or the user may
> +        have asked for it to be removed. Further changes to the surface will be
> +        ignored. The client should destroy the resource after receiving this
> +        event, and create a new surface if they so choose.
> +      </description>
> +    </event>
> +
> +    <enum name="error">
> +      <entry name="invalid_surface_state" value="0" summary="provided surface state is invalid"/>
> +      <entry name="invalid_size" value="1" summary="size is invalid"/>
> +      <entry name="invalid_anchor" value="2" summary="anchor bitfield is invalid"/>
> +    </enum>
> +
> +    <enum name="anchor" bitfield="true">
> +      <entry name="top" value="1" summary="the top edge of the anchor rectangle"/>
> +      <entry name="bottom" value="2" summary="the bottom edge of the anchor rectangle"/>
> +      <entry name="left" value="4" summary="the left edge of the anchor rectangle"/>
> +      <entry name="right" value="8" summary="the right edge of the anchor rectangle"/>
> +    </enum>
> +  </interface>
> +</protocol>
> -- 
> 2.17.0
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 2018-05-08 11:23 AM, Jonas Ådahl wrote:
> So the purpose here is to provide a way to allow constructing a desktop
> environment by combining different components more or less arbitrarily.
> I also assume this is a newer version of the one proposed
> earlier[0][1][2].

Aye.

> 1) The protocols distributed should be seen as functionality a client
> can potentially expect from any compositor.

I disagree. I think that the scope should be functionality several
compositors and/or clients implement. wayland.xml is for functionality a
client can expect from any compositor.

> 2) Things for constructing and/or configuring a desktop environment will
> often need to be privileged, which is not something we handle currently.
> This is a reason we have always avoided anything similar to a
> "wl_randr", and I expect panels and similar things have similar
> complications and requirements.

We are of the opinion that these protocols will not need to change as
means of securing them are added.

> It is my opinion that we should continue with the scope described above,
> to make a clear separation between what portable clients can expect
> while expecting to work both on highly integrated environments and less
> integrated environments alike.
> 
> With all this being said, this obviously doesn't mean one can not make a
> Wayland DE out of a multitude of third party components; wayland (the
> repository and tarball) and wayland-protocols are not the only way to
> distribute protocols. There is already wayland-wall[3] which aims to
> cover the use case for building a desktop environment by combining
> different components, and there is no reason why we can't have more
> sources (maybe a future test suite for example?).

I don't think anyone is interested in wayland-wall. wayland-protocols is
a better place for this. wayland-protocols already has many protocols
that don't make sense for all compositors: fullscreen-shell doesn't make
sense in many compositors, xwayland-keyboard-grab should probably live
in the xwayland tree by your arguments, and protocols like
pointer-gestures are unlikely to ever see an implementation in my
compositor.

It's better if wayland-protocols doesn't have the goal of collecting
"blessed" protocols that everyone is supposed to implement. The protocol
everyone is supposed to implement is wayland.xml. Instead, we should use
it to provide a review process for protocols common across the
ecosystem. One of the biggest complaints people have about Wayland is
the lack of cooperation between compositors. Lots of stuff users rely
on breaks during the transition because none of us can agree on how to
make these kinds of "desktop extension" clients. Instead of sitting in
an ivory tower of design, we are better off by acknowleding our user's
needs and making interopable protocols together. That doesn't mean
everyone has to play ball, but for those that want to, wayland-protocols
shouldn't be in our way.

I understand that it would probably be bad to take a bunch of protocols
that no one has any stake in, this is why I disagree with wayland-wall.
However, layer-shell has the backing of 5 compositor implementations
(likely to be 6 soon) and has many client implementations. Is the role
of wayland-protocols to be a small few who judge the worthiness of
protocols for inclusion, or an instrument of the community? Because the
community supports this protocol.

--
Drew DeVault
On Tue, May 08, 2018 at 08:01:25AM -0400, Drew DeVault wrote:
> On 2018-05-08 11:23 AM, Jonas Ådahl wrote:
> > So the purpose here is to provide a way to allow constructing a desktop
> > environment by combining different components more or less arbitrarily.
> > I also assume this is a newer version of the one proposed
> > earlier[0][1][2].
> 
> Aye.
> 
> > 1) The protocols distributed should be seen as functionality a client
> > can potentially expect from any compositor.
> 
> I disagree. I think that the scope should be functionality several
> compositors and/or clients implement. wayland.xml is for functionality a
> client can expect from any compositor.

This is not the original intention of wayland-protocols. It should be
thought of as a continuation of wayland.xml, rather than a bag of
arbitrary protocols that happen to have multiple compositor
implementations.

Also, what ended up in wayland.xml is also somewhat arbitrary
unfortunately. We should probably have split out a few parts of it
before going 1.0. It would definitely have avoided some inconveniences.

Anyway, that's not something we can do anything about now except adding
some disclaimer in the documentation about not using it (i.e. wl_shell),
or maybe adding "deprecated" attributes to the XML format.

> 
> > 2) Things for constructing and/or configuring a desktop environment will
> > often need to be privileged, which is not something we handle currently.
> > This is a reason we have always avoided anything similar to a
> > "wl_randr", and I expect panels and similar things have similar
> > complications and requirements.
> 
> We are of the opinion that these protocols will not need to change as
> means of securing them are added.
> 
> > It is my opinion that we should continue with the scope described above,
> > to make a clear separation between what portable clients can expect
> > while expecting to work both on highly integrated environments and less
> > integrated environments alike.
> > 
> > With all this being said, this obviously doesn't mean one can not make a
> > Wayland DE out of a multitude of third party components; wayland (the
> > repository and tarball) and wayland-protocols are not the only way to
> > distribute protocols. There is already wayland-wall[3] which aims to
> > cover the use case for building a desktop environment by combining
> > different components, and there is no reason why we can't have more
> > sources (maybe a future test suite for example?).
> 
> I don't think anyone is interested in wayland-wall. wayland-protocols is
> a better place for this. wayland-protocols already has many protocols
> that don't make sense for all compositors: fullscreen-shell doesn't make
> sense in many compositors, xwayland-keyboard-grab should probably live
> in the xwayland tree by your arguments, and protocols like
> pointer-gestures are unlikely to ever see an implementation in my
> compositor.

There are a couple of protocols that might not belong there, true. The
fullscreen shell is a good example that somehow made sense at the time,
and xwayland grab might have been better suited to be distributed as
part of X indeed, I agree. Another example is the input method protocol,
which I somewhat question suitability.

Missing pointer gestures support is also fine; that's part of the point;
it's an optional extension and a client will most likely work good
enough without it, but it's still mostly a continuation of what
wl_pointer provides.

> 
> It's better if wayland-protocols doesn't have the goal of collecting
> "blessed" protocols that everyone is supposed to implement. The protocol
> everyone is supposed to implement is wayland.xml.

Again, think of wayland-protocols as the continuation of wayland.xml,
not as some arbitrary collection. Today, a client can most likely not
just use what's in wayland.xml but will explicitly rely on something
outside of it, for example xdg-shell.

> Instead, we should use
> it to provide a review process for protocols common across the
> ecosystem. One of the biggest complaints people have about Wayland is
> the lack of cooperation between compositors. Lots of stuff users rely
> on breaks during the transition because none of us can agree on how to
> make these kinds of "desktop extension" clients. Instead of sitting in
> an ivory tower of design, we are better off by acknowleding our user's
> needs and making interopable protocols together. That doesn't mean
> everyone has to play ball, but for those that want to, wayland-protocols
> shouldn't be in our way.

I think you put too much value in providing a single entry point for all
protocols, when there are no practical reasons for requiring it.
Separation here is good, as it creates a clear distinction of what a
client can expect. Maybe what we need is another repository under
wayland/, explicitly for desktop components. This is assuming it is made
very clear that the APIs provided there is not something a regular
third party application can rely on and expect to be portable in any
way. The new version of the input-method protocol would be a good
contestant to adding there as well maybe.

> 
> I understand that it would probably be bad to take a bunch of protocols
> that no one has any stake in, this is why I disagree with wayland-wall.
> However, layer-shell has the backing of 5 compositor implementations
> (likely to be 6 soon) and has many client implementations. Is the role
> of wayland-protocols to be a small few who judge the worthiness of
> protocols for inclusion, or an instrument of the community? Because the
> community supports this protocol.

I think you are again misunderstanding my intentions here; this is not
about "worthiness", but about what kind of use cases that are in scope
where.


Jonas

> 
> --
> Drew DeVault
Hi,

On 8 May 2018 at 01:48, Drew DeVault <sir@cmpwn.com> wrote:
> The layer-shell introduces the concept of desktop "layers", each of
> which has a collection of surfaces. The layer shell affords its clients
> some freedom over how their surfaces are arranged with respect to each
> other and the available space on the output.
>
> The goal of this shell is to allow end-users and compositor authors to
> write desktop components and extensions which are portable across
> compositors. Use-cases include wallpapers, panels/taskbars, lock
> screens, notification daemons, etc; which will work correctly on any
> compositor which implements this protocol.

Unless I'm missing something, taskbars need a separate protocol to
communicate the task list, tell the compositor to raise/activate the
surfaces for that task, etc. I guess lock screens would be handled by
the 'overlay' mode, though that makes me incredibly itchy for the
security implications of having a lock state the compositor is unaware
of.

> This underwent a pretty grueling review process on our own team over at
> wlroots. A review of this discussion may answer some of the questions
> you have:
>
> https://github.com/swaywm/wlr-protocols/pull/7

This discussion mentions (amongst quite a lot of other things, some
fairly unpleasant) that access to layer-shell _must_ be locked down to
trusted clients only, which everyone takes as a given. That really
seems like it's worth mentioning in the introduction, though it
contradicts the 'broad number of other applications' line.

From a purely Weston point of view, I'm not at all sure how we'd go
about authenticating arbitrary (from the compositor's point of view,
i.e. not launched in a trusted way?) third-party clients, so don't
know how we'd go about implementing this in that compositor. Ideas
welcome, of course.

> The benefit of all of these implementations is that we've already spent
> a fair bit of time perfecting and proving this protocol's utility and
> design. However, everyone is prepared to make changes as the protocol
> evolves on the mailing list.

This was an interesting read. From a high level though, there's a fair
bit of overlap with the IVI shell, which also exposes the same concept
of stacked layers (and surface attachment to layers), out to clients.
Historically ivi-shell has also included its own wl_shell/xdg_shell
alternative for apps, but Michael Tayfel's recent patchset (which I
think is a good thing) deprecates that by letting the IVI shell expose
xdg-shell to clients.

Maybe there could be a good future in merging this with a rationalised
IVI shell?

Cheers,
Daniel
> > I understand that it would probably be bad to take a bunch of protocols
> > that no one has any stake in, this is why I disagree with wayland-wall.
> > However, layer-shell has the backing of 5 compositor implementations
> > (likely to be 6 soon) and has many client implementations. Is the role
> > of wayland-protocols to be a small few who judge the worthiness of
> > protocols for inclusion, or an instrument of the community? Because the
> > community supports this protocol.
> 
> I think you are again misunderstanding my intentions here; this is not
> about "worthiness", but about what kind of use cases that are in scope
> where.

My question is: who defines the scope?

> > I disagree. I think that the scope should be functionality several
> > compositors and/or clients implement. wayland.xml is for functionality a
> > client can expect from any compositor.
> 
> This is not the original intention of wayland-protocols. It should be
> thought of as a continuation of wayland.xml, rather than a bag of
> arbitrary protocols that happen to have multiple compositor
> implementations.

The original intention and what it's now become are two different
things, a fact we seem to agree on. I think we should embrace what it
has become.

> Missing pointer gestures support is also fine; that's part of the point;
> it's an optional extension and a client will most likely work good
> enough without it, but it's still mostly a continuation of what
> wl_pointer provides.

I disagree that the idea that pointer gestures is a continuation of
wl_pointer is a valid characterization of that protocol. I also think
that any client which can work equally well without it is a client which
has no reason to use it.

> Again, think of wayland-protocols as the continuation of wayland.xml,
> not as some arbitrary collection. Today, a client can most likely not
> just use what's in wayland.xml but will explicitly rely on something
> outside of it, for example xdg-shell.

xdg-shell is already not appropriate for every Wayland compositor.
That's why IVI shell exists, for instance. If wayland-protocols is
taking a desktop stance, then layer-shell belongs. If it's taking a more
general stance, then layer-shell belongs.

> I think you put too much value in providing a single entry point for all
> protocols, when there are no practical reasons for requiring it.
> Separation here is good, as it creates a clear distinction of what a
> client can expect. Maybe what we need is another repository under
> wayland/, explicitly for desktop components. This is assuming it is made
> very clear that the APIs provided there is not something a regular
> third party application can rely on and expect to be portable in any
> way. The new version of the input-method protocol would be a good
> contestant to adding there as well maybe.

I think I put an appropriate amount of value in having a single entry
point. This is a place where every compositor has a stake and a reason
to collaborate. I also think it would be very folly to remove
input-method from this repository. If we were to start down this road,
the first thing I'd put forth for removal is xdg-shell.

> Anyway, that's not something we can do anything about now except adding
> some disclaimer in the documentation about not using it (i.e. wl_shell),
> or maybe adding "deprecated" attributes to the XML format.

Aside: I'm in favor of a deprecated attribute in the XML format, and
we're working on sunsetting wl_shell for good over in wlroots. There may
soon be a patch from one of us adding deprecation support to
wayland-scanner.

--
Drew DeVault
On Tue, May 08, 2018 at 09:29:25AM -0400, Drew DeVault wrote:
> > > I understand that it would probably be bad to take a bunch of protocols
> > > that no one has any stake in, this is why I disagree with wayland-wall.
> > > However, layer-shell has the backing of 5 compositor implementations
> > > (likely to be 6 soon) and has many client implementations. Is the role
> > > of wayland-protocols to be a small few who judge the worthiness of
> > > protocols for inclusion, or an instrument of the community? Because the
> > > community supports this protocol.
> > 
> > I think you are again misunderstanding my intentions here; this is not
> > about "worthiness", but about what kind of use cases that are in scope
> > where.
> 
> My question is: who defines the scope?

The scope is not defined anywhere. What I'm communicating here is my
opinion, what the original intention of wayland-protocols was, but what
it actually is has always been a bit loose.

> 
> > > I disagree. I think that the scope should be functionality several
> > > compositors and/or clients implement. wayland.xml is for functionality a
> > > client can expect from any compositor.
> > 
> > This is not the original intention of wayland-protocols. It should be
> > thought of as a continuation of wayland.xml, rather than a bag of
> > arbitrary protocols that happen to have multiple compositor
> > implementations.
> 
> The original intention and what it's now become are two different
> things, a fact we seem to agree on. I think we should embrace what it
> has become.

That is not really true. It still mainly consists of protocols that can
be seen as a continuation, and I don't think we should give up on that
idea.

> 
> > Missing pointer gestures support is also fine; that's part of the point;
> > it's an optional extension and a client will most likely work good
> > enough without it, but it's still mostly a continuation of what
> > wl_pointer provides.
> 
> I disagree that the idea that pointer gestures is a continuation of
> wl_pointer is a valid characterization of that protocol. I also think
> that any client which can work equally well without it is a client which
> has no reason to use it.

An application that can act on gestures (e.g. zoom on pinch) still has a
valid reason to use it, because using gestures might be useful, but
it'll still work "good enough" without it. The same applies to
wp_viewporter; a client can crop and scale client side, but there are
benefits by using wp_viewporter. They are both useful components in
building a regular portable application.

> 
> > Again, think of wayland-protocols as the continuation of wayland.xml,
> > not as some arbitrary collection. Today, a client can most likely not
> > just use what's in wayland.xml but will explicitly rely on something
> > outside of it, for example xdg-shell.
> 
> xdg-shell is already not appropriate for every Wayland compositor.
> That's why IVI shell exists, for instance. If wayland-protocols is
> taking a desktop stance, then layer-shell belongs. If it's taking a more
> general stance, then layer-shell belongs.

It is not explicitly taking a desktop stance, but the xdg_ prefixed ones
somewhat do though. But they still aim explicitly at third party regular
applications, which is what I'm trying to emphasize here. Would we need
to add a "phone" based shell, assuming xdg_* isn't appropriate, it'd
according to be in scope because it's aimed at clients wanting to be
portable.


Jonas

> 
> > I think you put too much value in providing a single entry point for all
> > protocols, when there are no practical reasons for requiring it.
> > Separation here is good, as it creates a clear distinction of what a
> > client can expect. Maybe what we need is another repository under
> > wayland/, explicitly for desktop components. This is assuming it is made
> > very clear that the APIs provided there is not something a regular
> > third party application can rely on and expect to be portable in any
> > way. The new version of the input-method protocol would be a good
> > contestant to adding there as well maybe.
> 
> I think I put an appropriate amount of value in having a single entry
> point. This is a place where every compositor has a stake and a reason
> to collaborate. I also think it would be very folly to remove
> input-method from this repository. If we were to start down this road,
> the first thing I'd put forth for removal is xdg-shell.
> 
> > Anyway, that's not something we can do anything about now except adding
> > some disclaimer in the documentation about not using it (i.e. wl_shell),
> > or maybe adding "deprecated" attributes to the XML format.
> 
> Aside: I'm in favor of a deprecated attribute in the XML format, and
> we're working on sunsetting wl_shell for good over in wlroots. There may
> soon be a patch from one of us adding deprecation support to
> wayland-scanner.
> 
> --
> Drew DeVault
On 2018-05-08  2:24 PM, Daniel Stone wrote:
> Unless I'm missing something, taskbars need a separate protocol to
> communicate the task list, tell the compositor to raise/activate the
> surfaces for that task, etc. I guess lock screens would be handled by
> the 'overlay' mode, though that makes me incredibly itchy for the
> security implications of having a lock state the compositor is unaware
> of.

Depends on the taskbar. We expect to be working with KDE in the future
to draw up protocols for this as well, though. Also, we have a separate
protocol coming down the line later for helping lock screens out:

https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-input-inhibitor-unstable-v1.xml

Feel free to take an early look, but let's keep the discussion focused
on layer-shell instead of picking this protocol apart too.

> This discussion mentions (amongst quite a lot of other things, some
> fairly unpleasant) that access to layer-shell _must_ be locked down to
> trusted clients only, which everyone takes as a given. That really
> seems like it's worth mentioning in the introduction, though it
> contradicts the 'broad number of other applications' line.

We have some nebulous plans for opening up "locked down" protocols to
third parties in a secure way in the future. Again, taking the
discussion in this direction could get out of scope for layer-shell
pretty quick. Maybe we need to shelve this and discuss how to provide
secure access to privledged protocols to third-parties first, but we're
confident that the ideas we're thinking about will work (they're mostly
building on top of what Weston already does to seucre its desktop
shell).

I agree that the discussion on earlier versions of the protocol brought
up some unpleasant consequences of the early design decisions. However,
we redesigned those parts until we got what we believe is a pretty solid
protocol.

> From a purely Weston point of view, I'm not at all sure how we'd go
> about authenticating arbitrary (from the compositor's point of view,
> i.e. not launched in a trusted way?) third-party clients, so don't
> know how we'd go about implementing this in that compositor. Ideas
> welcome, of course.

Just to give a quick overview of what we have in mind, we start by
opening the socket ourselves and noting that the wl_client has some set
of permissions, then we fork from the compositor and use WAYLAND_SOCKET
instead of WAYLAND_DISPLAY for the client connection. Weston does
something like this at compositor/main.c:weston_client_launch.

On top of this we want to build some simple protocols subprocesses can
use to grant a subset of their permissions to their own children. This
would probably be as simple as a list of interface names they're allowed
to bind to. The compositor could combine this knowledge with global
filtering to clean up the loose ends.

These ideas are still somewhat nebulous but I'm confident enough that
it'll work that I think we can proceed with the discussion on protocols
like layer-shell. Compositors which are interested in implementing these
protocols and securing them today can do something simple like
weston_client_launch as a temporary solution and make it more accessible
to third parties later.

> This was an interesting read. From a high level though, there's a fair
> bit of overlap with the IVI shell, which also exposes the same concept
> of stacked layers (and surface attachment to layers), out to clients.
> Historically ivi-shell has also included its own wl_shell/xdg_shell
> alternative for apps, but Michael Tayfel's recent patchset (which I
> think is a good thing) deprecates that by letting the IVI shell expose
> xdg-shell to clients.
> 
> Maybe there could be a good future in merging this with a rationalised
> IVI shell?

I think it might be possible to replace IVI shell with layer shell (or
replace a subset of IVI shell with layer shell), but I'm not sure that
the other way around is a great plan. I also find it highly questionable
to repurpose xdg-shell in places like IVI (e.g. in a non-desktop
setting); I think it's far better to define new shells.

For some context, in wlroots we're already accustomed to the idea of
several distinct shells. We used to have a Grand Unified Shell
Abstraction when we were based on wlc, but learned our lesson and moved
to a new approach. Today, we have a "view" abstraction, but it's rather
thin and not all shell surfaces are views. For example, Xwayland
unmanaged surfaces are supported, but do not participate in the view
abstraction. Layer surfaces also do not participate in the view
abstraction. And even for those who do use the view abstraction, it's a
very thin abstraction, and consumers of views are exposed to
shell-specific concerns. This is more work, but allows us to have _much_
better support for each shell.

In short, we think that embracing the differences between shells is a
better design than attempting to fit a square peg in a variety of holes.

--
Drew DeVault
On 2018-05-08  3:53 PM, Jonas Ådahl wrote:
> That is not really true. It still mainly consists of protocols that can
> be seen as a continuation, and I don't think we should give up on that
> idea.

I think this is an overly optimistic view of the current list of
protocols. Of the protocols, I think your description applies to:

- input-timestamps
- presentation-time
- xdg-output
- tablet
- relative-pointer
- pointer-constraints

The rest of them are dubiously characterized as logical extensions of
wayland.xml in my opinion. I don't see this as a bad thing, to be clear.

> It is not explicitly taking a desktop stance, but the xdg_ prefixed ones
> somewhat do though. But they still aim explicitly at third party regular
> applications, which is what I'm trying to emphasize here. Would we need
> to add a "phone" based shell, assuming xdg_* isn't appropriate, it'd
> according to be in scope because it's aimed at clients wanting to be
> portable.

Just because GNOME, for example, might not implement this protocol
doesn't make it non-portable. "Desktop component" clients which hope to
be portable will use this protocol, and there are tens of examples of
clients which qualify (I can list some if you're not familiar with
them). If they use layer-shell, they can expect to work on at least 5
compositors, and likely more in the future. If this isn't portable, what
is? Do they have to support GNOME to qualify as portable?

You didn't acknowledge this point, but I'd like to once again raise that
if you want wayland-protocols to be a logical extension of wayland.xml
that all compositors are expected to implement, the first item on the
chopping block is xdg-shell. This isn't hypothetical - there are
compositors out there today for which xdg-shell is ill-suited. IVI shell
exists for this very reason. xdg-shell is poorly suited to phones as
well.

Of course, I'm playing devil's advocate here. I don't think we should
remove xdg-shell. But it's presence makes it hard to deny layer-shell
entry on the grounds of scope.

--
Drew DeVault
Hi Drew,

On 8 May 2018 at 14:56, Drew DeVault <sir@cmpwn.com> wrote:
> On 2018-05-08  2:24 PM, Daniel Stone wrote:
>> Unless I'm missing something, taskbars need a separate protocol to
>> communicate the task list, tell the compositor to raise/activate the
>> surfaces for that task, etc. I guess lock screens would be handled by
>> the 'overlay' mode, though that makes me incredibly itchy for the
>> security implications of having a lock state the compositor is unaware
>> of.
>
> Depends on the taskbar. We expect to be working with KDE in the future
> to draw up protocols for this as well, though. Also, we have a separate
> protocol coming down the line later for helping lock screens out:
>
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-input-inhibitor-unstable-v1.xml
>
> Feel free to take an early look, but let's keep the discussion focused
> on layer-shell instead of picking this protocol apart too.

Fair enough. I brought it up only because of the introductory text: I
think having some more context/disclaimers/etc would help.

>> This discussion mentions (amongst quite a lot of other things, some
>> fairly unpleasant) that access to layer-shell _must_ be locked down to
>> trusted clients only, which everyone takes as a given. That really
>> seems like it's worth mentioning in the introduction, though it
>> contradicts the 'broad number of other applications' line.
>
> We have some nebulous plans for opening up "locked down" protocols to
> third parties in a secure way in the future. Again, taking the
> discussion in this direction could get out of scope for layer-shell
> pretty quick. Maybe we need to shelve this and discuss how to provide
> secure access to privledged protocols to third-parties first, but we're
> confident that the ideas we're thinking about will work (they're mostly
> building on top of what Weston already does to seucre its desktop
> shell).

Sure, that makes sense. On the other hand, given that everyone agreed
from the get-go that this protocol needed to be locked down to
authorised clients only, I think nailing this down would help. At the
moment some of the crucial details you need to know as an implementer
are tucked away behind URLs, which might lead people implementing it
to badly screw it up.

> [... details snipped ...]
>
> These ideas are still somewhat nebulous but I'm confident enough that
> it'll work that I think we can proceed with the discussion on protocols
> like layer-shell. Compositors which are interested in implementing these
> protocols and securing them today can do something simple like
> weston_client_launch as a temporary solution and make it more accessible
> to third parties later.

I think they sound like a fine idea; is anyone working on implementing them?

>> This was an interesting read. From a high level though, there's a fair
>> bit of overlap with the IVI shell, which also exposes the same concept
>> of stacked layers (and surface attachment to layers), out to clients.
>> Historically ivi-shell has also included its own wl_shell/xdg_shell
>> alternative for apps, but Michael Tayfel's recent patchset (which I
>> think is a good thing) deprecates that by letting the IVI shell expose
>> xdg-shell to clients.
>>
>> Maybe there could be a good future in merging this with a rationalised
>> IVI shell?
>
> I think it might be possible to replace IVI shell with layer shell (or
> replace a subset of IVI shell with layer shell), but I'm not sure that
> the other way around is a great plan. I also find it highly questionable
> to repurpose xdg-shell in places like IVI (e.g. in a non-desktop
> setting); I think it's far better to define new shells.

I think maybe we're talking across each other?

There are three parts in play here:
  * running generic applications (a browser, mail client, image
viewer) under some kind of environment (let's call these 'apps')
  * running desktop component clients (background, home screen, panel)
under a specific environment (let's call these 'non-app clients')
  * running an external client which controls stacking, focus, other
window management, of both apps and non-app clients (let's call these
'external WM')

'ivi-shell' is all three of those.

[I'm going to pithily call systems with a UI composed of external
non-app clients 'building-block clients' as shorthand; feel free to
suggest other terminology and I'll be happy to use it!]

For apps, the 'ivi-shell' they use to extend wl_surface is pretty much
dead. What ivi-shell offered apps (compared to xdg_shell) wasn't
really that helpful, and what ivi-shell _didn't_ offer compared to
xdg_shell was a real gap. The IVI developers looked at it and
concluded that having an IVI compositor offer xdg_shell to apps was
the best thing to do; Michael Tayfel's last patchset is something that
got discussed a lot by all the IVI users, and everyone agreed it was
the best thing to do. Porting every app was just far too painful.

Non-app clients and external WMs receive the same interface, which
allows both to create layers, place surfaces into layers, stack both
surfaces and layers, and some more ephemera on top.

layer-shell obviously doesn't duplicate the app interface, and it's
not designed (I don't think? I only read the wlr-protocols pull
though, not the external ones) to support external WMs. But maybe
coming up with a common expression of layers (and their relationship
to surfaces) would be helpful, non-app clients for both IVI and
building-block compositors could then use the same. Obviously IVI
external WMs would need a separate interface, and maybe both
building-block systems and IVI systems would need to extend on top of
the common layer protocol for their own needs. But that's cool, I
think xdg-surface has shown that actually works better than everyone
completely going their own way.

> For some context, in wlroots we're already accustomed to the idea of
> several distinct shells. We used to have a Grand Unified Shell
> Abstraction when we were based on wlc, but learned our lesson and moved
> to a new approach. Today, we have a "view" abstraction, but it's rather
> thin and not all shell surfaces are views. For example, Xwayland
> unmanaged surfaces are supported, but do not participate in the view
> abstraction. Layer surfaces also do not participate in the view
> abstraction. And even for those who do use the view abstraction, it's a
> very thin abstraction, and consumers of views are exposed to
> shell-specific concerns. This is more work, but allows us to have _much_
> better support for each shell.
>
> In short, we think that embracing the differences between shells is a
> better design than attempting to fit a square peg in a variety of holes.

Given the above, I'm not sure whether I violently agree or totally
disagree with you here: which components are you talking about? :)

Cheers,
Daniel
Hi, butting in

On 2018/May/08 04:17, Daniel Stone wrote:
> 
> > [... details snipped ...]
> >
> > These ideas are still somewhat nebulous but I'm confident enough that
> > it'll work that I think we can proceed with the discussion on protocols
> > like layer-shell. Compositors which are interested in implementing these
> > protocols and securing them today can do something simple like
> > weston_client_launch as a temporary solution and make it more accessible
> > to third parties later.
> 
> I think they sound like a fine idea; is anyone working on implementing them?

If I remember correctly and you are talking about the spawn with filters, I 
have a basic implementation/PoC in waymonad. I haven't implemented it too far 
for accesibility yet, but it works reasonably well from my testing.
I also have plans to implement this for containers (based on additional 
sockets to accept on "manually"), but haven't gotten around to it.

Cheers,
ongy
On May 8, 2018 6:23:30 PM GMT+09:00, "Jonas Ådahl" <jadahl@gmail.com> wrote:

>It is my opinion that we should continue with the scope described
>above,
>to make a clear separation between what portable clients can expect
>while expecting to work both on highly integrated environments and less
>integrated environments alike.

I understand wanting to avoid a scenario where every compositor collapses under peer pressure to implement every protocol under the sun, but a think it's a secondary concern to the "lots of junk in many private silos" problem.

There's a lot of value to subsets of the greater Wayland implementation community collaborating and agreeing on things when they have overlapping needs (which they do, as can be shown by example). Compared to keeping protocols to ourselves which could easily interest multiple stakeholders, it leads to better, more generic protocols that compose/complement better, while avoiding redundancy. It means accumulating less tech debt across a lot of software, which is ultimately good for users.

It's good for wayland-protocols to be the space this happens in, because it's where the necessary engineering culture exists to hold protocol development to consistent quality standards. And that's without getting into the interoperability benefits.

Limiting wayland-protocols to "expected to implement/be provided" protocols is that it doesn't allow all this good stuff to happen. At the very least there's definitely ways to avoid unmitigated sprawl, e.g. checklists to avoid redundant protocols and "does too much" protocols. The peer pressure problem I'm not sure how to address, but I am also not convinced it'd actually materialize in practice. In reality when it does it'd usually be driven by users wishing to get things to interoperate, which indicates a need, which should be met somehow and to the best quality possible - cf. xdg-toplevel-decoration.

I understand the worry about getting swept away by a tide that won't be stemmed. But right now there's more desire for collaboration than there is a venue for, and I'm more worried about the opportunity cost to protocol and software quality that comes with it. If in doubt, maximizing collaboration usually makes for more durable stuff.

layer-shell: We are interested. It does things we already have working with a protocol proprietary to Plasma, but better, as it's more focused and generalized and has seen more review already than we could muster internally at the time. Between that and the users who are asking us for more interoperability whenever possible it's attractive.

Cheers,
Eike
On 2018-05-08  4:17 PM, Daniel Stone wrote:
> Fair enough. I brought it up only because of the introductory text: I
> think having some more context/disclaimers/etc would help.

Yeah there'll be a PATCHv2 in the future elaborating on that.

> > These ideas are still somewhat nebulous but I'm confident enough that
> > it'll work that I think we can proceed with the discussion on protocols
> > like layer-shell. Compositors which are interested in implementing these
> > protocols and securing them today can do something simple like
> > weston_client_launch as a temporary solution and make it more accessible
> > to third parties later.
> 
> I think they sound like a fine idea; is anyone working on implementing them?

No, not yet. It's something we intend to push for before sway 1.0,
though.

> There are three parts in play here:
>   * running generic applications (a browser, mail client, image
> viewer) under some kind of environment (let's call these 'apps')
>   * running desktop component clients (background, home screen, panel)
> under a specific environment (let's call these 'non-app clients')
>   * running an external client which controls stacking, focus, other
> window management, of both apps and non-app clients (let's call these
> 'external WM')
> 
> 'ivi-shell' is all three of those.
>
> --%<--

I see, and I think I better understand how these protocols are supposed
to work now. 

> layer-shell obviously doesn't duplicate the app interface, and it's
> not designed (I don't think? I only read the wlr-protocols pull
> though, not the external ones) to support external WMs. But maybe
> coming up with a common expression of layers (and their relationship
> to surfaces) would be helpful, non-app clients for both IVI and
> building-block compositors could then use the same. Obviously IVI
> external WMs would need a separate interface, and maybe both
> building-block systems and IVI systems would need to extend on top of
> the common layer protocol for their own needs. But that's cool, I
> think xdg-surface has shown that actually works better than everyone
> completely going their own way.

A unified layer abstraction could be interesting, but the ivi shell
protocol is too generic for me to understand the use-cases they're
trying to fulfill with their layers. Also, some layer-shell concepts
like anchors and exclusive zones are foreign to ivi-shell. Inversely,
some ivi-shell concepts are undesirable in layer-shell, particularly
allowing clients to arrange themselves directly with x/y/width/height.

Overall I don't think integrating ivi-shell and layer-shell with each
other would be good. I might be convinced with more discussion.

> > In short, we think that embracing the differences between shells is a
> > better design than attempting to fit a square peg in a variety of holes.
> 
> Given the above, I'm not sure whether I violently agree or totally
> disagree with you here: which components are you talking about? :)

I think your 3 categories of client is not a long enough list. In
particular I would split this one up:

>   * running generic applications (a browser, mail client, image
> viewer) under some kind of environment (let's call these 'apps')

I strongly disagree with the decision to have xdg-toplevels handle their
own movement, resizing, and so on. But at this point, we have to live
with it, and this causes me to characterize xdg-toplevel applications as
being suitable _only_ to the desktop. IVI and phones and so on have
different requirements that aren't served by xdg-toplevel. So I'd change
your category to "desktop" applications and add another:

* "phone-style" (for lack of a better term) applications (a browser,
  mail client, image viewer) which can expect to not manage its own size
  or position on screen.

This necessitates a separate shell. Maybe this shell uses xdg-surface...
but I see very little advantage in doing so. Using xdg-toplevel would be
totally nuts.

--
Drew DeVault