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 ----- _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
