[PATCH] xdg-shell: remove constraints for fullscreen

[Jonas Ådahl]

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel