[PATCHv3] Add surface-layers protocol

[Jonas Ådahl]

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