[PATCH] Add layer-shell-unstable-v1.xml
Jonas Ådahl
jadahl at gmail.com
Tue May 8 09:23:30 UTC 2018
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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list