[PATCH] xdg-shell: remove constraints for fullscreen
jadahl at gmail.com
Wed Jun 19 20:41:26 UTC 2019
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.
> <arg name="output" type="object" interface="wl_output" allow-null="true"/>
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel