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

[Eike Hein]

On May 8, 2018 6:23:30 PM GMT+09:00, "Jonas Ådahl" <jadahl at gmail.com> wrote:

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

I understand wanting to avoid a scenario where every compositor collapses under peer pressure to implement every protocol under the sun, but a think it's a secondary concern to the "lots of junk in many private silos" problem.

There's a lot of value to subsets of the greater Wayland implementation community collaborating and agreeing on things when they have overlapping needs (which they do, as can be shown by example). Compared to keeping protocols to ourselves which could easily interest multiple stakeholders, it leads to better, more generic protocols that compose/complement better, while avoiding redundancy. It means accumulating less tech debt across a lot of software, which is ultimately good for users.

It's good for wayland-protocols to be the space this happens in, because it's where the necessary engineering culture exists to hold protocol development to consistent quality standards. And that's without getting into the interoperability benefits.

Limiting wayland-protocols to "expected to implement/be provided" protocols is that it doesn't allow all this good stuff to happen. At the very least there's definitely ways to avoid unmitigated sprawl, e.g. checklists to avoid redundant protocols and "does too much" protocols. The peer pressure problem I'm not sure how to address, but I am also not convinced it'd actually materialize in practice. In reality when it does it'd usually be driven by users wishing to get things to interoperate, which indicates a need, which should be met somehow and to the best quality possible - cf. xdg-toplevel-decoration.

I understand the worry about getting swept away by a tide that won't be stemmed. But right now there's more desire for collaboration than there is a venue for, and I'm more worried about the opportunity cost to protocol and software quality that comes with it. If in doubt, maximizing collaboration usually makes for more durable stuff.

layer-shell: We are interested. It does things we already have working with a protocol proprietary to Plasma, but better, as it's more focused and generalized and has seen more review already than we could muster internally at the time. Between that and the users who are asking us for more interoperability whenever possible it's attractive.

Cheers,
Eike