[PATCHv3] Add surface-layers protocol

[Drew DeVault]

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