[PATCHv3] Add surface-layers protocol

Submitted by Drew DeVault on Jan. 25, 2017, 12:47 a.m.

Details

Message ID 20170125004730.GA8396@homura
State New
Headers show
Series "Add surface-layers protocol" ( rev: 3 ) in Wayland

Not browsing as part of any series.

Commit Message

Drew DeVault Jan. 25, 2017, 12:47 a.m.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
---
This revision addresses much of Yong's feedback. It changes some of the
language to more closely match other protocols, fixes a few typos, and
clarifies some descriptions. I disagree with the use of a bitfield for
anchors in xdg-shell et al, but I chose to reuse that design per Yong's
suggestion, for the sake of consistency. I chose not to add many
descriptions as Yong suggested, where I felt that the nature of the
fields were self-evident.

Cheers!

 unstable/surface-layers/README             |   4 +
 unstable/surface-layers/surface-layers.xml | 151 +++++++++++++++++++++++++++++
 2 files changed, 155 insertions(+)
 create mode 100644 unstable/surface-layers/README
 create mode 100644 unstable/surface-layers/surface-layers.xml

Patch hide | download patch | download mbox

diff --git a/unstable/surface-layers/README b/unstable/surface-layers/README
new file mode 100644
index 0000000..662f488
--- /dev/null
+++ b/unstable/surface-layers/README
@@ -0,0 +1,4 @@ 
+Surface layers protocol
+
+Maintainers:
+Drew DeVault <sir@cmpwn.com>
diff --git a/unstable/surface-layers/surface-layers.xml b/unstable/surface-layers/surface-layers.xml
new file mode 100644
index 0000000..fe621ef
--- /dev/null
+++ b/unstable/surface-layers/surface-layers.xml
@@ -0,0 +1,151 @@ 
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="surface_layers">
+
+  <copyright>
+    Copyright © 2017 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="surface_layers" 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>
+
+    <enum name="surface_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. Multiple
+        surfaces can share a single layer.
+      </description>
+
+      <entry name="background" value="0"/>
+      <entry name="bottom" value="1"/>
+      <entry name="top" value="2"/>
+      <entry name="overlay" value="3"/>
+    </enum>
+
+    <request name="get_layer_surface">
+      <descripton 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.
+      </description>
+      <arg name="id" type="new_id" interface="layer_surface"/>
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="output" type="object" interface="wl_output"/>
+      <arg name="layer" type="uint" summary="surface_layer to add this surface to"/>
+    </request>
+  </interface>
+
+  <interface name="layer_surface" 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.
+    </description>
+
+    <enum name="input_devices">
+      <descripton summary="types of input devices">
+        These flags are a bitfield and are used by set_interactive to specify
+        what sorts of input the surface should interact with.
+      </description>
+      <arg name="none" value="0x0" />
+      <arg name="pointer" value="0x1" />
+      <arg name="keyboard" value="0x2" />
+      <arg name="touch" value="0x4" />
+    </enum>
+
+    <request name="set_interactivity">
+      <description summary="indicates that this surface is interactive">
+        This request indicates to the compositor what kind of interactivity this
+        surface requires. This may be changed at runtime. Note that whether or
+        not the compositor chooses to send the surface input events at any given
+        time is implementation-dependent. Any events from input devices you do not
+        ask for will be passed along to other clients, also in an
+        implementation-dependent way.
+
+        By convention, conventional compositors will send input events to
+        surfaces below the shell surface layer when there are no shell surfaces
+        or when the surface is clicked (and thus receives focus). Above the
+        shell surface layer, the topmost surface receives all input of the types
+        it requests.
+      </description>
+      <arg name="types" type="uint" summary="mask of input devices to use"/>
+    </request>
+
+    <enum name="anchor" bitfield="true">
+      <entry name="none" value="0"
+       summary="the center of the anchor rectangle"/>
+      <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>
+
+    <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.
+      </description>
+      <arg name="anchor" type="uint"/>
+    </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.
+
+        This value is only meaningful if the surface is anchored to an edge,
+        rather than a corner. The zone is the number of pixels from the edge
+        that are considered exclusive.
+      </description>
+      <arg name="zone" type="uint"/>
+    </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 pixels.
+      </description>
+      <arg name="horizontal" type="uint"/>
+      <arg name="vertical" type="uint"/>
+    </request>
+  </interface>
+
+</protocol>

Comments

Hi,

By the looks of it, this is a protocol extension that aims to enable
desktop environments to be built of interoperable components (i.e. a
"background" process to draw a (live?) wallpaper, an "overlay" thing
could be used to create a panel, popup launcher or alt-tab view or
something). Is this correct?

If so, I believe this type of protocols, and probably many others
similar to this one (there have been others passing by wayland-devel as
well), would be best suited "wayland-wall"[0] or something similar,
where modular compositor developers who want to choose what type of
modularity they want to support can pick at their discretion.

Thus, I don't think it is suitable for wayland-protocols, as I think the
focus of it should rather be an extension of Wayland proper
(wayland.xml) where client and compositor developers can look for
protocols that can be considered relatively portable. "Modular
compositor" protocols mostly cannot be portable in the same sense.

If I misunderstood the intention of the protocol, do let me know. I
didn't see any use cases spelled out, so I am just assuming.

Maybe it would make sense to link wayland-wall from
wayland.freedesktop.org as a possible path to take for "modular
compositor" developers looking for protocols for components? Are there
any other projects trying to do the same?


Jonas

[0] https://github.com/wayland-wall/wayland-wall

On Tue, Jan 24, 2017 at 07:47:30PM -0500, Drew DeVault wrote:
> Signed-off-by: Drew DeVault <sir@cmpwn.com>
> ---
> This revision addresses much of Yong's feedback. It changes some of the
> language to more closely match other protocols, fixes a few typos, and
> clarifies some descriptions. I disagree with the use of a bitfield for
> anchors in xdg-shell et al, but I chose to reuse that design per Yong's
> suggestion, for the sake of consistency. I chose not to add many
> descriptions as Yong suggested, where I felt that the nature of the
> fields were self-evident.
> 
> Cheers!
> 
>  unstable/surface-layers/README             |   4 +
>  unstable/surface-layers/surface-layers.xml | 151 +++++++++++++++++++++++++++++
>  2 files changed, 155 insertions(+)
>  create mode 100644 unstable/surface-layers/README
>  create mode 100644 unstable/surface-layers/surface-layers.xml
> 
> diff --git a/unstable/surface-layers/README b/unstable/surface-layers/README
> new file mode 100644
> index 0000000..662f488
> --- /dev/null
> +++ b/unstable/surface-layers/README
> @@ -0,0 +1,4 @@
> +Surface layers protocol
> +
> +Maintainers:
> +Drew DeVault <sir@cmpwn.com>
> diff --git a/unstable/surface-layers/surface-layers.xml b/unstable/surface-layers/surface-layers.xml
> new file mode 100644
> index 0000000..fe621ef
> --- /dev/null
> +++ b/unstable/surface-layers/surface-layers.xml
> @@ -0,0 +1,151 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="surface_layers">
> +
> +  <copyright>
> +    Copyright © 2017 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="surface_layers" 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>
> +
> +    <enum name="surface_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. Multiple
> +        surfaces can share a single layer.
> +      </description>
> +
> +      <entry name="background" value="0"/>
> +      <entry name="bottom" value="1"/>
> +      <entry name="top" value="2"/>
> +      <entry name="overlay" value="3"/>
> +    </enum>
> +
> +    <request name="get_layer_surface">
> +      <descripton 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.
> +      </description>
> +      <arg name="id" type="new_id" interface="layer_surface"/>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +      <arg name="output" type="object" interface="wl_output"/>
> +      <arg name="layer" type="uint" summary="surface_layer to add this surface to"/>
> +    </request>
> +  </interface>
> +
> +  <interface name="layer_surface" 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.
> +    </description>
> +
> +    <enum name="input_devices">
> +      <descripton summary="types of input devices">
> +        These flags are a bitfield and are used by set_interactive to specify
> +        what sorts of input the surface should interact with.
> +      </description>
> +      <arg name="none" value="0x0" />
> +      <arg name="pointer" value="0x1" />
> +      <arg name="keyboard" value="0x2" />
> +      <arg name="touch" value="0x4" />
> +    </enum>
> +
> +    <request name="set_interactivity">
> +      <description summary="indicates that this surface is interactive">
> +        This request indicates to the compositor what kind of interactivity this
> +        surface requires. This may be changed at runtime. Note that whether or
> +        not the compositor chooses to send the surface input events at any given
> +        time is implementation-dependent. Any events from input devices you do not
> +        ask for will be passed along to other clients, also in an
> +        implementation-dependent way.
> +
> +        By convention, conventional compositors will send input events to
> +        surfaces below the shell surface layer when there are no shell surfaces
> +        or when the surface is clicked (and thus receives focus). Above the
> +        shell surface layer, the topmost surface receives all input of the types
> +        it requests.
> +      </description>
> +      <arg name="types" type="uint" summary="mask of input devices to use"/>
> +    </request>
> +
> +    <enum name="anchor" bitfield="true">
> +      <entry name="none" value="0"
> +       summary="the center of the anchor rectangle"/>
> +      <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>
> +
> +    <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.
> +      </description>
> +      <arg name="anchor" type="uint"/>
> +    </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.
> +
> +        This value is only meaningful if the surface is anchored to an edge,
> +        rather than a corner. The zone is the number of pixels from the edge
> +        that are considered exclusive.
> +      </description>
> +      <arg name="zone" type="uint"/>
> +    </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 pixels.
> +      </description>
> +      <arg name="horizontal" type="uint"/>
> +      <arg name="vertical" type="uint"/>
> +    </request>
> +  </interface>
> +
> +</protocol>
> -- 
> 2.11.0
>
On 2017-01-25  9:54 AM, Jonas Ådahl wrote:
> Hi,
> 
> By the looks of it, this is a protocol extension that aims to enable
> desktop environments to be built of interoperable components (i.e. a
> "background" process to draw a (live?) wallpaper, an "overlay" thing
> could be used to create a panel, popup launcher or alt-tab view or
> something). Is this correct?
>
> ...
>
> If I misunderstood the intention of the protocol, do let me know. I
> didn't see any use cases spelled out, so I am just assuming.

You're correct. There are numerous other use-cases this enables that
you're missing, though. Here's a few that come to mind:

- dmenu/rofi style applications
- slop style applications
- an android-like notification drawer

As well as basic desktop components like:

- screen locks and screensavers
- on screen keyboards
- panels
- wallpapers (live or otherwise)
- desktop icons

I put forth some use-cases in my initial proposal, but I've repeated
them here.

> If so, I believe this type of protocols, and probably many others
> similar to this one (there have been others passing by wayland-devel as
> well), would be best suited "wayland-wall"[0] or something similar,
> where modular compositor developers who want to choose what type of
> modularity they want to support can pick at their discretion.
> 
> Thus, I don't think it is suitable for wayland-protocols, as I think the
> focus of it should rather be an extension of Wayland proper
> (wayland.xml) where client and compositor developers can look for
> protocols that can be considered relatively portable. "Modular
> compositor" protocols mostly cannot be portable in the same sense.

I have a few arguments to pose in response to this. Not all of this is
in response to your specific concerns, but I'll extrapolate this
discussion a bit based on what I expect to hear based on previous
discussions.

1. surface-layers learns from previous proposals

Similar protocols have been discussed here before, and have been largely
rejected. I designed this protocol with the benefit of hindsight. The
motivation behind rejecting many of these, I believe, is that they're
too specific. Weston's desktop-shell.xml isn't suitable for
wayland-protocols because it explicitly outlines the supported use-cases
as things like panels and wallpapers and such, that specifically
accommodate a likely Weston-specific desktop shell.

This protocol (and the ones that will follow) support the same
uses-cases, but are much more generic and applicable to a wide variety
of compositors. As a consequence they also support a much wider range of
use-cases than i.e. desktop-shell.xml. I'm sure you'll agree that this
protocol can support many use cases we haven't though of, whereas
desktop-shell.xml's wallpaper interfaces are tied quite closely to the
specific use-case of wallpapers.

2. wayland-protocols and wayland.xml already make similar and more
   egregious assumptions

I summarize this aspect of your viewpoint as a desire to avoid
desktop-specific paradigms leaking into core Wayland bits, and a desire
for Wayland to support more novel compositor designs than the desktop.
However, I think that (1) the damage is already done, and (2)
surface-layers is conservative in this regard anyway.

Design choices have already landed in wayland-protocols and wayland.xml
that are closely associated with a desktop UX. xdg-shell has interfaces
which have clearly been designed to accommodate a traditional desktop UX
and traditional UI toolkit designs. It includes features like the
positioner, which only really exists to support context menus;
minimizing and maximising; the implication that xdg surfaces are
floating windows that are user-resizable with a mouse.

wayland.xml itself has several similar assumptions, including features
like drag-and-drop and clipboard support. Both of these are arguably
outside of the scope of wayland.xml, have clear origins in the desktop
UX, and have questionable re-applicability for novel compositor designs.

surface-layers is comparatively much more conservative. The only
assumption it makes about the compositor is that the wl_outputs have
edges. wayland.xml implies this and more about outputs, including things
like the idea that outputs may be rotated along one axis, that they have
a two-dimensional position in global compositor space, a width and
height (thus are rectangular), modes (and with them resolutions and
refresh rates - specifically vertical refresh rates). None of this is
relevant to a compositor that uses 3D space, for example, which there is
already a functional PoC of in the wild. We can assume, as
surface-layers does, that outputs have edges or at least that a novel
compositor has implemented some workaround to support wayland.xml
anyway.

3. The desktop players stand to benefit from surface-layers, or at least
   don't have anything to lose from it

I believe the desktop shells components of the major players can be
implemented based on surface-layers.xml - and if that's not true, point
out where it's lacking and let's try to shore it up. Basing your desktop
shell on surface-layers is likely to simplify your design, if nothing
else.

The major players on Wayland have done a poor job at cooperating to
produce reusable components. The walled garden of each compositor is
incredibly harmful to Wayland's adoption. There's not much use to making
a more secure and maintainable Linux desktop if no one will switch to it
because you can only use GNOME software on it and it doesn't support
their favorite application. So far the major players have been very
hostile to the idea of designing their software to be usable across
platforms, GNOME even going so far as to not care about GTK software
running sanely on anything but GNOME. This attitude is very
disappointing.

Even if the major players don't care about reusability, protocols like
surface-layers are a better design than what's in place now.
Implementing protocols like this will improve your compositor. As a free
(or cheap) side effect, it would be nice if some of your components ran
on other compositors, and it would be nice if third parties could expand
the desktop experience in ways you haven't thought of.

--
Drew DeVault
On Tue, Jan 24, 2017 at 10:03:05PM -0500, Drew DeVault wrote:
> On 2017-01-25  9:54 AM, Jonas Ådahl wrote:
> > Hi,
> > 
> > By the looks of it, this is a protocol extension that aims to enable
> > desktop environments to be built of interoperable components (i.e. a
> > "background" process to draw a (live?) wallpaper, an "overlay" thing
> > could be used to create a panel, popup launcher or alt-tab view or
> > something). Is this correct?
> >
> > ...
> >
> > If I misunderstood the intention of the protocol, do let me know. I
> > didn't see any use cases spelled out, so I am just assuming.
> 
> You're correct. There are numerous other use-cases this enables that
> you're missing, though. Here's a few that come to mind:
> 
> - dmenu/rofi style applications
> - slop style applications
> - an android-like notification drawer
> 
> As well as basic desktop components like:
> 
> - screen locks and screensavers
> - on screen keyboards
> - panels
> - wallpapers (live or otherwise)
> - desktop icons
> 
> I put forth some use-cases in my initial proposal, but I've repeated
> them here.
> 
> > If so, I believe this type of protocols, and probably many others
> > similar to this one (there have been others passing by wayland-devel as
> > well), would be best suited "wayland-wall"[0] or something similar,
> > where modular compositor developers who want to choose what type of
> > modularity they want to support can pick at their discretion.
> > 
> > Thus, I don't think it is suitable for wayland-protocols, as I think the
> > focus of it should rather be an extension of Wayland proper
> > (wayland.xml) where client and compositor developers can look for
> > protocols that can be considered relatively portable. "Modular
> > compositor" protocols mostly cannot be portable in the same sense.
> 
> I have a few arguments to pose in response to this. Not all of this is
> in response to your specific concerns, but I'll extrapolate this
> discussion a bit based on what I expect to hear based on previous
> discussions.
> 
> 1. surface-layers learns from previous proposals
> 
> Similar protocols have been discussed here before, and have been largely
> rejected. I designed this protocol with the benefit of hindsight. The
> motivation behind rejecting many of these, I believe, is that they're
> too specific. Weston's desktop-shell.xml isn't suitable for
> wayland-protocols because it explicitly outlines the supported use-cases
> as things like panels and wallpapers and such, that specifically
> accommodate a likely Weston-specific desktop shell.

No. desktop-shell.xml is not suitable because it an implementation
detail of the sample desktop shell of weston. It's just one piece of
code, standing next to a bunch of C files. It has never had any
intention of being an exposed API, just as weston/desktop-shell/shell.h
is not. Being generic or not, is irrelevant.

> 
> This protocol (and the ones that will follow) support the same
> uses-cases, but are much more generic and applicable to a wide variety
> of compositors. As a consequence they also support a much wider range of
> use-cases than i.e. desktop-shell.xml. I'm sure you'll agree that this
> protocol can support many use cases we haven't though of, whereas
> desktop-shell.xml's wallpaper interfaces are tied quite closely to the
> specific use-case of wallpapers.
> 
> 2. wayland-protocols and wayland.xml already make similar and more
>    egregious assumptions
> 
> I summarize this aspect of your viewpoint as a desire to avoid
> desktop-specific paradigms leaking into core Wayland bits, and a desire
> for Wayland to support more novel compositor designs than the desktop.
> However, I think that (1) the damage is already done, and (2)
> surface-layers is conservative in this regard anyway.
> 
> Design choices have already landed in wayland-protocols and wayland.xml
> that are closely associated with a desktop UX. xdg-shell has interfaces
> which have clearly been designed to accommodate a traditional desktop UX
> and traditional UI toolkit designs. It includes features like the
> positioner, which only really exists to support context menus;
> minimizing and maximising; the implication that xdg surfaces are
> floating windows that are user-resizable with a mouse.
> 
> wayland.xml itself has several similar assumptions, including features
> like drag-and-drop and clipboard support. Both of these are arguably
> outside of the scope of wayland.xml, have clear origins in the desktop
> UX, and have questionable re-applicability for novel compositor designs.
> 
> surface-layers is comparatively much more conservative. The only
> assumption it makes about the compositor is that the wl_outputs have
> edges. wayland.xml implies this and more about outputs, including things
> like the idea that outputs may be rotated along one axis, that they have
> a two-dimensional position in global compositor space, a width and
> height (thus are rectangular), modes (and with them resolutions and
> refresh rates - specifically vertical refresh rates). None of this is
> relevant to a compositor that uses 3D space, for example, which there is
> already a functional PoC of in the wild. We can assume, as
> surface-layers does, that outputs have edges or at least that a novel
> compositor has implemented some workaround to support wayland.xml
> anyway.

You are misunderstanding. I'm not saying desktop-centered concepts
should not be in wayland-protocols; it's perfectly suitable, and
desirable to have certain things related to the desktop paradigm there.
What I'm talking about is the modular construction of desktop
environments. Writing a "panel" in a way that can be expected to be
portable everywhere will simply not be possible. It only partly is on
X11; having a custom panel on e.g. gnome-shell on X11 isn't really.
Writing a panel that is compatible with a certian subset of desktop
environments (i.e. those that aim to be modular and support a particular
protocol) can very much be made possible, but I believe we should have a
logical separation between the two concepts. wayland-wall to me seems to
be a perfectly fine solution to this.

And FWIW, you are right, certain things added to wl_output might have
been a mistake, and in some compositors the values there needs to be
awkwardly faked, which is sad.

> 
> 3. The desktop players stand to benefit from surface-layers, or at least
>    don't have anything to lose from it
> 
> I believe the desktop shells components of the major players can be
> implemented based on surface-layers.xml - and if that's not true, point
> out where it's lacking and let's try to shore it up. Basing your desktop
> shell on surface-layers is likely to simplify your design, if nothing
> else.

I'm not saying there is anything wrong with the layer approach, but
it'll most likely not be something that can be relied upon by
non-desktop-component type clients, as for example weston (sample
desktop shell) and gnome-shell with little doubt will not add support
for it, as it is simply out of scope.

> 
> The major players on Wayland have done a poor job at cooperating to
> produce reusable components. The walled garden of each compositor is
> incredibly harmful to Wayland's adoption. There's not much use to making
> a more secure and maintainable Linux desktop if no one will switch to it
> because you can only use GNOME software on it and it doesn't support
> their favorite application. So far the major players have been very
> hostile to the idea of designing their software to be usable across
> platforms, GNOME even going so far as to not care about GTK software
> running sanely on anything but GNOME. This attitude is very
> disappointing.

If GTK+ software doesn't run sanely on non-GNOME platforms, do open a
bug, so it can be tracked and fixed, as I'm not aware of the issues you
are referring to.

> 
> Even if the major players don't care about reusability, protocols like
> surface-layers are a better design than what's in place now.
> Implementing protocols like this will improve your compositor. As a free
> (or cheap) side effect, it would be nice if some of your components ran
> on other compositors, and it would be nice if third parties could expand
> the desktop experience in ways you haven't thought of.

Regarding reusable components, that might be true, which is why the DEs
that want to go for the modular approach should gather around common
ground and come up with the interfaces they want to share. This is as
far as I know the exact intention of wayland-wall.


Jonas

> 
> --
> Drew DeVault
On 2017-01-25 11:37 AM, Jonas Ådahl wrote:
> No. desktop-shell.xml is not suitable because it an implementation
> detail of the sample desktop shell of weston. It's just one piece of
> code, standing next to a bunch of C files. It has never had any
> intention of being an exposed API, just as weston/desktop-shell/shell.h
> is not. Being generic or not, is irrelevant.

desktop-shell is just an adequate example that doesn't rely on anyone's
memory of rejected proposals in times past.

> You are misunderstanding. I'm not saying desktop-centered concepts
> should not be in wayland-protocols; it's perfectly suitable, and
> desirable to have certain things related to the desktop paradigm there.
> What I'm talking about is the modular construction of desktop
> environments. Writing a "panel" in a way that can be expected to be
> portable everywhere will simply not be possible. It only partly is on
> X11; having a custom panel on e.g. gnome-shell on X11 isn't really.

You're using failings in X11 to justify failings in Wayland. And I don't
really expect Gnome to try and support third party desktop shell
components on Gnome, nor vice versa. However, Gnome would likely benefit
from this approach to their own desktop shell and would gain the
advantage of compatibility with a broader set of software. Switching to
Wayland doesn't have to demand sacrifices to the end user's workflow -
IF compositors participate in these sorts of efforts.

> I'm not saying there is anything wrong with the layer approach, but
> it'll most likely not be something that can be relied upon by
> non-desktop-component type clients, as for example weston (sample
> desktop shell) and gnome-shell with little doubt will not add support
> for it, as it is simply out of scope.

You may be surprised by how many clients will rely on it. Something of
this sort is certainly going to land in Sway. Many useful programs will
be developed to take advantage of it; I personally have spoken with
several authors intending to make such projects. I wouldn't be surprised
if something to this effect could land in KDE and many of the smaller
compositors as well. Gnome would be the exception, and would support a
smaller set of useful software.

Gnome should not so coyly prepared to ask users give up tools like OBS,
slop, and so on. Gnome will never be able to fully support the gap left
in their wake, and shouldn't try, really. The target audience for these
sorts of customizations are hackers and tinkerers. This audience has a
significant intersection with the sorts of people who might contribute
to Gnome in the future. Should they really be alienated?

I'm prepared to write the patches for the major compositors to implement
this protocol, perhaps with help from some other Sway contributors who
share this common goal.

> If GTK+ software doesn't run sanely on non-GNOME platforms, do open a
> bug, so it can be tracked and fixed, as I'm not aware of the issues you
> are referring to.

Sorry, I couldn't find the discussion I got this impression from.
Consider it retracted.

> Regarding reusable components, that might be true, which is why the DEs
> that want to go for the modular approach should gather around common
> ground and come up with the interfaces they want to share. This is as
> far as I know the exact intention of wayland-wall.

Resistance to these sorts of protocols leads to fragmentation that is
harmful to Wayland, Linux, and software as a whole. If not curbed, I
shudder to imagine the state of the Linux desktop in 10 years. I intend
to argue for these protocols until they land in the major compositors.
However, I'm not so hopelessly optimistic to have any illusions about
Gnome or other major players getting on board with wayland-wall. I don't
even intend to get on board with wayland-wall. Even if the compositors
were on board with it, however, I still don't agree that this protocol
belongs there. It's well suited to wayland-protocols.

--
Drew DeVault