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

[Drew DeVault]

On 2018-05-08  4:17 PM, Daniel Stone wrote:
> Fair enough. I brought it up only because of the introductory text: I
> think having some more context/disclaimers/etc would help.

Yeah there'll be a PATCHv2 in the future elaborating on that.

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

No, not yet. It's something we intend to push for before sway 1.0,
though.

> 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 see, and I think I better understand how these protocols are supposed
to work now. 

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

A unified layer abstraction could be interesting, but the ivi shell
protocol is too generic for me to understand the use-cases they're
trying to fulfill with their layers. Also, some layer-shell concepts
like anchors and exclusive zones are foreign to ivi-shell. Inversely,
some ivi-shell concepts are undesirable in layer-shell, particularly
allowing clients to arrange themselves directly with x/y/width/height.

Overall I don't think integrating ivi-shell and layer-shell with each
other would be good. I might be convinced with more discussion.

> > 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? :)

I think your 3 categories of client is not a long enough list. In
particular I would split this one up:

>   * running generic applications (a browser, mail client, image
> viewer) under some kind of environment (let's call these 'apps')

I strongly disagree with the decision to have xdg-toplevels handle their
own movement, resizing, and so on. But at this point, we have to live
with it, and this causes me to characterize xdg-toplevel applications as
being suitable _only_ to the desktop. IVI and phones and so on have
different requirements that aren't served by xdg-toplevel. So I'd change
your category to "desktop" applications and add another:

* "phone-style" (for lack of a better term) applications (a browser,
  mail client, image viewer) which can expect to not manage its own size
  or position on screen.

This necessitates a separate shell. Maybe this shell uses xdg-surface...
but I see very little advantage in doing so. Using xdg-toplevel would be
totally nuts.

--
Drew DeVault