[PATCH] Add layer-shell-unstable-v1.xml
daniel at fooishbar.org
Tue May 8 13:24:56 UTC 2018
On 8 May 2018 at 01:48, Drew DeVault <sir at cmpwn.com> wrote:
> The layer-shell introduces the concept of desktop "layers", each of
> which has a collection of surfaces. The layer shell affords its clients
> some freedom over how their surfaces are arranged with respect to each
> other and the available space on the output.
> The goal of this shell is to allow end-users and compositor authors to
> write desktop components and extensions which are portable across
> compositors. Use-cases include wallpapers, panels/taskbars, lock
> screens, notification daemons, etc; which will work correctly on any
> compositor which implements this protocol.
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
> This underwent a pretty grueling review process on our own team over at
> wlroots. A review of this discussion may answer some of the questions
> you have:
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.
>From a purely Weston point of view, I'm not at all sure how we'd go
about authenticating arbitrary (from the compositor's point of view,
i.e. not launched in a trusted way?) third-party clients, so don't
know how we'd go about implementing this in that compositor. Ideas
welcome, of course.
> The benefit of all of these implementations is that we've already spent
> a fair bit of time perfecting and proving this protocol's utility and
> design. However, everyone is prepared to make changes as the protocol
> evolves on the mailing list.
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
More information about the wayland-devel