[PATCH 2/2] xdg-shell: Make sure wording reflects expectations

[Mike Blumenkrantz]

Hi,

This seems like a reasonable direction for a change, though I would suggest
a slightly different approach. For all cases where it reads "the compositor
will respond by emitting", instead change to something like "if the
compositor decides to apply this state change then it will respond by
emitting". Such change clarifies the mechanism, as your patch intends,
while also preserving the requirement that the compositor emits a state and
geometry in a configure event in order to acknowledge requests for state
changes.

Regards,
Mike

On Tue, Feb 27, 2018 at 7:25 AM <wl at ongy.net> wrote:

> From: Markus Ongyerth <wl at ongy.net>
>
> The wording in xdg-shell `set_*` requests implies the compositor *will*
> react to requests.
> This would give clients the control over its state, while they should
> just be able to kindly ask for a state change.
> This makes sure the language reflects that and changes "will" to "may"
> in the relevant requests description.
>
> Signed-off-by: Markus Ongyerth <wl at ongy.net>
> ---
>  stable/xdg-shell/xdg-shell.xml | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/stable/xdg-shell/xdg-shell.xml
> b/stable/xdg-shell/xdg-shell.xml
> index 0b21364..c619634 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -842,7 +842,7 @@
>         Maximize the surface.
>
>         After requesting that the surface should be maximized, the
> compositor
> -       will respond by emitting a configure event with the "maximized"
> state
> +       may respond by emitting a configure event with the "maximized"
> state
>         and the required window geometry. The client should then update its
>         content, drawing it in a maximized state. The client must also
>         acknowledge the configure when committing the new content (see
> @@ -852,11 +852,11 @@
>         surface, for example which output and what region of the screen
> should
>         be used.
>
> -       If the surface was already maximized, the compositor will still
> emit
> +       If the surface was already maximized, the compositor will emit
>         a configure event with the "maximized" state.
>
>         If the surface is in a fullscreen state, this request has no direct
> -       effect. It will alter the state the surface is returned to when
> +       effect. It may alter the state the surface is returned to when
>         unmaximized if not overridden by the compositor.
>        </description>
>      </request>
> @@ -866,7 +866,7 @@
>         Unmaximize the surface.
>
>         After requesting that the surface should be unmaximized, the
> compositor
> -       will respond by emitting a configure event without the "maximized"
> +       may respond by emitting a configure event without the "maximized"
>         state. If available, the compositor will include the window
> geometry
>         dimensions the window had prior to being maximized in the configure
>         event. The client must then update its content, drawing it in a
> @@ -878,11 +878,11 @@
>         unmaximized; usually the position the surface had before
> maximizing, if
>         applicable.
>
> -       If the surface was already not maximized, the compositor will still
> +       If the surface was already not maximized, the compositor will
>         emit a configure event without the "maximized" state.
>
>         If the surface is in a fullscreen state, this request has no direct
> -       effect. It will alter the state the surface is returned to when
> +       effect. It may alter the state the surface is returned to when
>         unmaximized if not overridden by the compositor.
>        </description>
>      </request>
> @@ -892,7 +892,7 @@
>         Make the surface fullscreen.
>
>         After requesting that the surface should be fullscreened, the
> -       compositor will respond by emitting a configure event with the
> +       compositor may respond by emitting a configure event with the
>         "fullscreen" state and the fullscreen window geometry. The client
> must
>         also acknowledge the configure when committing the new content (see
>         ack_configure).
> @@ -921,7 +921,7 @@
>         Make the surface no longer fullscreen.
>
>         After requesting that the surface should be unfullscreened, the
> -       compositor will respond by emitting a configure event without the
> +       compositor may respond by emitting a configure event without the
>         "fullscreen" state.
>
>         Making a surface unfullscreen sets states for the surface based on
> the following:
> --
> 2.16.2
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180227/46423246/attachment.html>