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

[Jonas Ådahl]

On Tue, May 08, 2018 at 08:01:25AM -0400, Drew DeVault wrote:
> 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.

This is not the original intention of wayland-protocols. It should be
thought of as a continuation of wayland.xml, rather than a bag of
arbitrary protocols that happen to have multiple compositor
implementations.

Also, what ended up in wayland.xml is also somewhat arbitrary
unfortunately. We should probably have split out a few parts of it
before going 1.0. It would definitely have avoided some inconveniences.

Anyway, that's not something we can do anything about now except adding
some disclaimer in the documentation about not using it (i.e. wl_shell),
or maybe adding "deprecated" attributes to the XML format.

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

There are a couple of protocols that might not belong there, true. The
fullscreen shell is a good example that somehow made sense at the time,
and xwayland grab might have been better suited to be distributed as
part of X indeed, I agree. Another example is the input method protocol,
which I somewhat question suitability.

Missing pointer gestures support is also fine; that's part of the point;
it's an optional extension and a client will most likely work good
enough without it, but it's still mostly a continuation of what
wl_pointer provides.

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

Again, think of wayland-protocols as the continuation of wayland.xml,
not as some arbitrary collection. Today, a client can most likely not
just use what's in wayland.xml but will explicitly rely on something
outside of it, for example xdg-shell.

> 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 think you put too much value in providing a single entry point for all
protocols, when there are no practical reasons for requiring it.
Separation here is good, as it creates a clear distinction of what a
client can expect. Maybe what we need is another repository under
wayland/, explicitly for desktop components. This is assuming it is made
very clear that the APIs provided there is not something a regular
third party application can rely on and expect to be portable in any
way. The new version of the input-method protocol would be a good
contestant to adding there as well maybe.

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

I think you are again misunderstanding my intentions here; this is not
about "worthiness", but about what kind of use cases that are in scope
where.


Jonas

> 
> --
> Drew DeVault