On Wed, Jun 19, 2019 at 01:35:42PM -0400, Drew DeVault wrote: > Compositors are free to render surfaces at their discretion. This > change clarifies that for xdg-shell's fullscreen surfaces. > --- > This point has been a recurring cause for frustration in Sway > development, as users expect windows beneath transparent fullscreen > windows to be shown. The main use-case for this, for example, is working > in a transparent full-screen terminal while referencing docs in a web > browser underneath. We hit this again for a different reason when > discussing a patch which would allow the user to arrange fullscreen > windows in a manner other than by using the entire screen. > > At least one other compositor in the wild (Wayfire) is also not > respecting these constraints. It is my intent to loosen this restriction > and start considering sway patches which change the behavior of > fullscreen in a manner inconsistent with these constraints. > > Since it's the compositors privilege to do anything it wants with > client surfaces, this updates the protocol text to reflect that, while > still suggesting the desired behavior. > > stable/xdg-shell/xdg-shell.xml | 18 ++++++++---------- > 1 file changed, 8 insertions(+), 10 deletions(-) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index 2e420c6..22ff93d 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -926,16 +926,14 @@ > it's up to the compositor to choose which display will be used to map > this surface. > > - If the surface doesn't cover the whole output, the compositor will > - position the surface in the center of the output and compensate with > - with border fill covering the rest of the output. The content of the > - border fill is undefined, but should be assumed to be in some way that > - attempts to blend into the surrounding area (e.g. solid black). > - > - If the fullscreened surface is not opaque, the compositor must make > - sure that other screen content not part of the same surface tree (made > - up of subsurfaces, popups or similarly coupled surfaces) are not > - visible below the fullscreened surface. > + The compositor should interpret this as a suggestion that the > fullscreened > + surface should be shown across the entire output, however, the specific > + position and sizing of the client on-screen is undefined. When the > + aspect ratio of the fullscreened surface is not equal to the aspect > + ratio of the space allocated for its display, the compositor should fill > + the remaining space in with a neutral background (e.g. solid black). If > + the surface is not opaque, the content (e.g. other surfaces) shown below > + the fullscreened surface is undefined.
This changes the semantics in a non-backward compatible way; clients relying on the currently defined behavior would break, so I'll have to nack this change. You'd have to add a `set_fullscreen_translucent` or something like that if the described behavior is needed. Jonas > </description> > <arg name="output" type="object" interface="wl_output" > allow-null="true"/> > </request> > -- > 2.22.0 > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
