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

[Drew DeVault]

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

My question is: who defines the scope?

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

The original intention and what it's now become are two different
things, a fact we seem to agree on. I think we should embrace what it
has become.

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

I disagree that the idea that pointer gestures is a continuation of
wl_pointer is a valid characterization of that protocol. I also think
that any client which can work equally well without it is a client which
has no reason to use it.

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

xdg-shell is already not appropriate for every Wayland compositor.
That's why IVI shell exists, for instance. If wayland-protocols is
taking a desktop stance, then layer-shell belongs. If it's taking a more
general stance, then layer-shell belongs.

> 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 think I put an appropriate amount of value in having a single entry
point. This is a place where every compositor has a stake and a reason
to collaborate. I also think it would be very folly to remove
input-method from this repository. If we were to start down this road,
the first thing I'd put forth for removal is xdg-shell.

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

Aside: I'm in favor of a deprecated attribute in the XML format, and
we're working on sunsetting wl_shell for good over in wlroots. There may
soon be a patch from one of us adding deprecation support to
wayland-scanner.

--
Drew DeVault