[PATCH] Add surface-layers protocol

[Drew DeVault]

Moving this discussion from off-list to on-list (with Bill's
permission):

On 2017-01-03 10:18 AM, Bill Spitzak wrote:
> This is probably a good idea, but I expect a lot of hostile reaction.
> You almost certainly need to have some way to limit ability to do this
> to certain clients that the compositor launches.

I expect mixed reactions as well. With respect to limiting the ability
to use this protocol, permission to do elevated things in general is a
much bigger can of worms - which is why, for now, I suggest leaving the
authorization part of this protocol undefined and suggesting that
compositors use it for their own shells and disallow the protocol for
anything else at the moment (unless, like sway, they already have a
means of securing sensitive protocols). We'll get to permissions in
later discussions, I'm sure.

> I think normally destroy does not do anything at all. You cannot
> assign another role, or recreate the layer_surface role, on the
> surface. All that can be done is to destroy the surface.

I included this based on my reading of the xdg-shell protocol, rather
than from an understanding why it was necessary. I figured it made a
reasonable amount of sense to want to destroy the role and assign
another, which the xdg-shell protocol implies is possible. If not, then
let's yank this function and just clean up when the surface is
destroyed. That's what I'd prefer design-wise anyway.

> I think event propagation controls should be separate from the layer
> api. If it is going to be supported it should be supported for any
> surface in any layer.

The propegation of input events for layer surfaces is logistically
different from shell surfaces, and I don't want to imply and sort of
protocol that governs the input behaviors of all surfaces (especially
since the sorts of behaviors a layer might impose are ones that should
be restricted to privledged clients).

> Hmm it sounds a little like you want to make a "take over the screen"
> api, by (I guess) using a full-screen top-layer surface that grabs the
> input types. It would probably be better to make this a different api,
> primarily because only one of these can exist at a time, and it
> probably should have some behavior like popup grabs in that there is a
> way for the user to get out of, perhaps on the next mouse release.

Right, this is intended to support things like lock screens and slop.
However, there might not only be one of them at a time - said surfaces
might be semi-transparent and not want to take over the entire UI, and
might not have to be alone. An example could be rofi, which would be
centered on the screen and take over keyboard input (come to think of
it, maybe a "center" anchor makes sense), but could co-exist with other
surfaces that are semi-transparent or take exclusive mouse input (how
would you slop to take a screenshot of rofi, for example?). Handling
input exclusively is also a seperate concern, as is the types of input
you want to handle.

Also for those things like lock surfaces, you don't _want_ the user to
be able to get out of it with anything short of entering their password
(which the lockscreen client should of course handle).

> > +    <request name="set_anchor">
> > +      <description summary="configures the anchor point of the surface">
> > +        Requests that the compositor anchor the surface to the specified corner
> > +        or edge. If your surface is not exclusive, it will be positioned with
> > +        respect to other exclusive surfaces (that is, it won't occlude them).
> 
> I'm guessing it would do this with exclusive surfaces too. If there
> are two conflicting exclusive surfaces, the second one is positioned
> to avoid the first one.

I leave this behavior to the best judgement of the compositor
implementation, which I also do for some other behaviors, to minimize
assumptions about the compositor (and their desktop shells).

> Can't it figure this out from the input area of the surface?

AFAIK input area is specific to shell surfaces. I also wanted to reduce
the complexity implementation-wise with respect to conflicts between
exclusive surfaces by making it one-dimensional.

> > +    <request name="set_margin">
> > +      <description summary="sets a margin from the anchor point">
> > +        Requests that the surface be placed some distance away from the anchor
> > +        point on the output, in pixels.
> > +      </description>
> > +      <arg name="horizontal" type="uint"/>
> > +      <arg name="vertical" type="uint"/>
> > +    </request>
> > +  </interface>
> 
> This sounds excessively complex of an api. Why not just let the client
> pick an xy position for the surface. The compositor can figure out if
> it is along an edge or not. It can ignore xy positions that are not on
> edges.

I was doing that in the first place, but I opted for this instead for a
few reasons:

- Margins are more semantically accurate representations of the behavior
  this models
- Ignoring invalid xy positions creates unexpected/unexplained behaviors
  without feedback
- This design removes some assumptions about the compositor design,
  which is feedback I've received in previous discussions about this
  sort of protocol

I pasted in your second email here:

>> +      <entry name="background" value="0"/>
>> +      <entry name="bottom" value="1"/>
>> +      <entry name="top" value="2"/>
>> +      <entry name="overlay" value="3"/>

> There is also a "layer" in the current compositors which is "below one
> of the full-screen surfaces". It is not clear if it is below the
> topmost or bottom-most full-screen surface. Yet I can imagine you
> still want to put surfaces above full-screen ones so that must be a
> different layer. My guess is that this is the difference between "top"
> and "overlay", but if not then another one is needed.

Yes, this is the difference between top and overlay. Top is, for
example, where notifications go. Overlay is, for example, where lock
screens go.

> It would probably be a good idea to make the layer for normal windows
> be called "normal" or "default" or something to make it obvious.

I did at first, but removed it because normal windows are not layer
surfaces and are not governed by this protocol. They cannot have two
roles. Internally it might make sense for the compositor to do this,
though.
 
--
Drew DeVault

----- End forwarded message -----