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

[Daniel Stone]

Hi Drew,

On 8 May 2018 at 14:56, Drew DeVault <sir at cmpwn.com> wrote:
> On 2018-05-08  2:24 PM, Daniel Stone wrote:
>> Unless I'm missing something, taskbars need a separate protocol to
>> communicate the task list, tell the compositor to raise/activate the
>> surfaces for that task, etc. I guess lock screens would be handled by
>> the 'overlay' mode, though that makes me incredibly itchy for the
>> security implications of having a lock state the compositor is unaware
>> of.
>
> Depends on the taskbar. We expect to be working with KDE in the future
> to draw up protocols for this as well, though. Also, we have a separate
> protocol coming down the line later for helping lock screens out:
>
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-input-inhibitor-unstable-v1.xml
>
> Feel free to take an early look, but let's keep the discussion focused
> on layer-shell instead of picking this protocol apart too.

Fair enough. I brought it up only because of the introductory text: I
think having some more context/disclaimers/etc would help.

>> This discussion mentions (amongst quite a lot of other things, some
>> fairly unpleasant) that access to layer-shell _must_ be locked down to
>> trusted clients only, which everyone takes as a given. That really
>> seems like it's worth mentioning in the introduction, though it
>> contradicts the 'broad number of other applications' line.
>
> We have some nebulous plans for opening up "locked down" protocols to
> third parties in a secure way in the future. Again, taking the
> discussion in this direction could get out of scope for layer-shell
> pretty quick. Maybe we need to shelve this and discuss how to provide
> secure access to privledged protocols to third-parties first, but we're
> confident that the ideas we're thinking about will work (they're mostly
> building on top of what Weston already does to seucre its desktop
> shell).

Sure, that makes sense. On the other hand, given that everyone agreed
from the get-go that this protocol needed to be locked down to
authorised clients only, I think nailing this down would help. At the
moment some of the crucial details you need to know as an implementer
are tucked away behind URLs, which might lead people implementing it
to badly screw it up.

> [... details snipped ...]
>
> These ideas are still somewhat nebulous but I'm confident enough that
> it'll work that I think we can proceed with the discussion on protocols
> like layer-shell. Compositors which are interested in implementing these
> protocols and securing them today can do something simple like
> weston_client_launch as a temporary solution and make it more accessible
> to third parties later.

I think they sound like a fine idea; is anyone working on implementing them?

>> This was an interesting read. From a high level though, there's a fair
>> bit of overlap with the IVI shell, which also exposes the same concept
>> of stacked layers (and surface attachment to layers), out to clients.
>> Historically ivi-shell has also included its own wl_shell/xdg_shell
>> alternative for apps, but Michael Tayfel's recent patchset (which I
>> think is a good thing) deprecates that by letting the IVI shell expose
>> xdg-shell to clients.
>>
>> Maybe there could be a good future in merging this with a rationalised
>> IVI shell?
>
> I think it might be possible to replace IVI shell with layer shell (or
> replace a subset of IVI shell with layer shell), but I'm not sure that
> the other way around is a great plan. I also find it highly questionable
> to repurpose xdg-shell in places like IVI (e.g. in a non-desktop
> setting); I think it's far better to define new shells.

I think maybe we're talking across each other?

There are three parts in play here:
  * running generic applications (a browser, mail client, image
viewer) under some kind of environment (let's call these 'apps')
  * running desktop component clients (background, home screen, panel)
under a specific environment (let's call these 'non-app clients')
  * running an external client which controls stacking, focus, other
window management, of both apps and non-app clients (let's call these
'external WM')

'ivi-shell' is all three of those.

[I'm going to pithily call systems with a UI composed of external
non-app clients 'building-block clients' as shorthand; feel free to
suggest other terminology and I'll be happy to use it!]

For apps, the 'ivi-shell' they use to extend wl_surface is pretty much
dead. What ivi-shell offered apps (compared to xdg_shell) wasn't
really that helpful, and what ivi-shell _didn't_ offer compared to
xdg_shell was a real gap. The IVI developers looked at it and
concluded that having an IVI compositor offer xdg_shell to apps was
the best thing to do; Michael Tayfel's last patchset is something that
got discussed a lot by all the IVI users, and everyone agreed it was
the best thing to do. Porting every app was just far too painful.

Non-app clients and external WMs receive the same interface, which
allows both to create layers, place surfaces into layers, stack both
surfaces and layers, and some more ephemera on top.

layer-shell obviously doesn't duplicate the app interface, and it's
not designed (I don't think? I only read the wlr-protocols pull
though, not the external ones) to support external WMs. But maybe
coming up with a common expression of layers (and their relationship
to surfaces) would be helpful, non-app clients for both IVI and
building-block compositors could then use the same. Obviously IVI
external WMs would need a separate interface, and maybe both
building-block systems and IVI systems would need to extend on top of
the common layer protocol for their own needs. But that's cool, I
think xdg-surface has shown that actually works better than everyone
completely going their own way.

> For some context, in wlroots we're already accustomed to the idea of
> several distinct shells. We used to have a Grand Unified Shell
> Abstraction when we were based on wlc, but learned our lesson and moved
> to a new approach. Today, we have a "view" abstraction, but it's rather
> thin and not all shell surfaces are views. For example, Xwayland
> unmanaged surfaces are supported, but do not participate in the view
> abstraction. Layer surfaces also do not participate in the view
> abstraction. And even for those who do use the view abstraction, it's a
> very thin abstraction, and consumers of views are exposed to
> shell-specific concerns. This is more work, but allows us to have _much_
> better support for each shell.
>
> In short, we think that embracing the differences between shells is a
> better design than attempting to fit a square peg in a variety of holes.

Given the above, I'm not sure whether I violently agree or totally
disagree with you here: which components are you talking about? :)

Cheers,
Daniel