[PATCH] Add layer-shell-unstable-v1.xml

[Drew DeVault]

On 2018-05-08 11:23 AM, Jonas Ådahl wrote:
> 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].

Aye.

> 1) The protocols distributed should be seen as functionality a client
> can potentially expect from any compositor.

I disagree. I think that the scope should be functionality several
compositors and/or clients implement. wayland.xml is for functionality a
client can expect from any compositor.

> 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.

We are of the opinion that these protocols will not need to change as
means of securing them are added.

> 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?).

I don't think anyone is interested in wayland-wall. wayland-protocols is
a better place for this. wayland-protocols already has many protocols
that don't make sense for all compositors: fullscreen-shell doesn't make
sense in many compositors, xwayland-keyboard-grab should probably live
in the xwayland tree by your arguments, and protocols like
pointer-gestures are unlikely to ever see an implementation in my
compositor.

It's better if wayland-protocols doesn't have the goal of collecting
"blessed" protocols that everyone is supposed to implement. The protocol
everyone is supposed to implement is wayland.xml. Instead, we should use
it to provide a review process for protocols common across the
ecosystem. One of the biggest complaints people have about Wayland is
the lack of cooperation between compositors. Lots of stuff users rely
on breaks during the transition because none of us can agree on how to
make these kinds of "desktop extension" clients. Instead of sitting in
an ivory tower of design, we are better off by acknowleding our user's
needs and making interopable protocols together. That doesn't mean
everyone has to play ball, but for those that want to, wayland-protocols
shouldn't be in our way.

I understand that it would probably be bad to take a bunch of protocols
that no one has any stake in, this is why I disagree with wayland-wall.
However, layer-shell has the backing of 5 compositor implementations
(likely to be 6 soon) and has many client implementations. Is the role
of wayland-protocols to be a small few who judge the worthiness of
protocols for inclusion, or an instrument of the community? Because the
community supports this protocol.

--
Drew DeVault