[PATCHv3] Add surface-layers protocol

[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