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

[Jonas Ådahl]

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

The scope is not defined anywhere. What I'm communicating here is my
opinion, what the original intention of wayland-protocols was, but what
it actually is has always been a bit loose.

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

That is not really true. It still mainly consists of protocols that can
be seen as a continuation, and I don't think we should give up on that
idea.

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

An application that can act on gestures (e.g. zoom on pinch) still has a
valid reason to use it, because using gestures might be useful, but
it'll still work "good enough" without it. The same applies to
wp_viewporter; a client can crop and scale client side, but there are
benefits by using wp_viewporter. They are both useful components in
building a regular portable application.

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

It is not explicitly taking a desktop stance, but the xdg_ prefixed ones
somewhat do though. But they still aim explicitly at third party regular
applications, which is what I'm trying to emphasize here. Would we need
to add a "phone" based shell, assuming xdg_* isn't appropriate, it'd
according to be in scope because it's aimed at clients wanting to be
portable.


Jonas

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