[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Kristian Høgsberg]

On Tue, Oct 15, 2013 at 8:05 AM,  <antognolli at gmail.com> wrote:
> From: Rafael Antognolli <rafael.antognolli at intel.com>
>
> These functions only differ from the previous one because they request
> that the given state is set, without changing the surface type, thus
> removing any previously state that was set on it.
>
> Both states can be used at the same time, and the states can be set or
> unset independently.
>
> NOTE: The original surface_set_maximized and surface_set_fullscreen
> requests were removed.

Hi Rafael,

Just to keep the list in the loop - we talked about how to send out
these patches and I think it's clearer if we just work on one patch
that adds the xdg-shell.xml file in one go instead of these two
patches.

Much of the discussion on the list around xdg_shell has been about the
surface states and how the server can initiate maximize or minimize
etc.  I think we mostly have consensus there, so I want to bring up a
few other points/ideas for xdg_shell.  These are a little un-edited,
but it's late here and I just want to start the discussion:

    - move/resize needs cursor_surface arg to avoid mismatch between
hover cursor and resize/move cursor.

    - transient for shouldn't take position.

    - We should add a _NET_WM_STATE_DEMANDS_ATTENTION equivalent

    - New keyboard focus protocol: instead of active surface meaning
"has keyboard focus" we need something that works in a touch-only
environment and we need a more generic way to create surfaces that
don't take keyboard focus.  I propose a new xdg_surface.activate event
that indicates that the surface has been activated (by clicking or
touching or alt-tabbing to it (or hovering in case of sloppy focus)).
When a surface is "the active surface", the client can choose to
assign kb focus (xdg_surface.take_keyboard_focus) to any of its
surfaces.

    - We need to solve stacking - how does a wayland shell raise an
applications and all its surfaces correctly.  The two ideas I have are
either 1) let the client raise its surfaces when it's active (uses the
same xdg_surface.activate event as above) and just let the client
control which surfaces to raise and in which order in response to
being activated or 2) let the client describe above/below relation
between its surfaces and make sure the shell respects these
constraints when raising a surface (eg, toolbars above documents, but
no relation between individual toolbar surfaces or doc surfaces.
Raising a document raises all the toolbox surfaces to be on top, but
doesn't affect other documents and preserves the stacking order of the
toolbox surface).

    - always on top, sticky; I think these are straight forward,
they're just flags an application can set.

    - If a compositor initiates a maximize, it should immediately
followed the event by a configure event so that the client does not
need to wait for a configure event in response to set_maximized.  just
a subtle tweak to avoid eliminate roundtrip.

Kristian


>  protocol/xdg-surface.xml | 149 ++++++++++++++++++++++++++++-------------------
>  1 file changed, 89 insertions(+), 60 deletions(-)
>
> diff --git a/protocol/xdg-surface.xml b/protocol/xdg-surface.xml
> index 4d2cc1b..b224fee 100644
> --- a/protocol/xdg-surface.xml
> +++ b/protocol/xdg-surface.xml
> @@ -170,47 +170,6 @@
>        <entry name="fill" value="3" summary="no upscaling, center on output and add black borders to compensate size mismatch"/>
>      </enum>
>
> -    <request name="set_fullscreen">
> -      <description summary="make the surface a fullscreen surface">
> -       Map the surface as a fullscreen surface.
> -
> -       If an output parameter is given then the surface will be made
> -       fullscreen on that output. If the client does not specify the
> -       output then the compositor will apply its policy - usually
> -       choosing the output on which the surface has the biggest surface
> -       area.
> -
> -       The client may specify a method to resolve a size conflict
> -       between the output size and the surface size - this is provided
> -       through the method parameter.
> -
> -       The framerate parameter is used only when the method is set
> -       to "driver", to indicate the preferred framerate. A value of 0
> -       indicates that the app does not care about framerate.  The
> -       framerate is specified in mHz, that is framerate of 60000 is 60Hz.
> -
> -       A method of "scale" or "driver" implies a scaling operation of
> -       the surface, either via a direct scaling operation or a change of
> -       the output mode. This will override any kind of output scaling, so
> -       that mapping a surface with a buffer size equal to the mode can
> -       fill the screen independent of buffer_scale.
> -
> -       A method of "fill" means we don't scale up the buffer, however
> -       any output scale is applied. This means that you may run into
> -       an edge case where the application maps a buffer with the same
> -       size of the output mode but buffer_scale 1 (thus making a
> -       surface larger than the output). In this case it is allowed to
> -       downscale the results to fit the screen.
> -
> -       The compositor must reply to this request with a configure event
> -       with the dimensions for the output on which the surface will
> -       be made fullscreen.
> -      </description>
> -      <arg name="method" type="uint"/>
> -      <arg name="framerate" type="uint"/>
> -      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
> -    </request>
> -
>      <request name="set_popup">
>        <description summary="make the surface a popup surface">
>         Map the surface as a popup.
> @@ -242,9 +201,34 @@
>        <arg name="flags" type="uint"/>
>      </request>
>
> -    <request name="set_maximized">
> -      <description summary="make the surface a maximized surface">
> -       Map the surface as a maximized surface.
> +    <request name="set_title">
> +      <description summary="set surface title">
> +       Set a short title for the surface.
> +
> +       This string may be used to identify the surface in a task bar,
> +       window list, or other user interface elements provided by the
> +       compositor.
> +
> +       The string must be encoded in UTF-8.
> +      </description>
> +      <arg name="title" type="string"/>
> +    </request>
> +
> +    <request name="set_class">
> +      <description summary="set surface class">
> +       Set a class for the surface.
> +
> +       The surface class identifies the general class of applications
> +       to which the surface belongs. A common convention is to use
> +       the file name (full path if non-standard location) of the
> +       applications .desktop file as the class.
> +      </description>
> +      <arg name="class_" type="string"/>
> +    </request>
> +
> +    <request name="state_set_maximized">
> +      <description summary="set the surface maximized state">
> +       Set the surface state as maximized.
>
>         If an output parameter is given then the surface will be
>         maximized on that output. If the client does not specify the
> @@ -262,33 +246,78 @@
>         fullscreen shell surface.
>
>         The details depend on the compositor implementation.
> +
> +       This state can be set while other surface states are still set,
> +       and it won't unset them.
>        </description>
>        <arg name="output" type="object" interface="wl_output" allow-null="true"/>
>      </request>
>
> -    <request name="set_title">
> -      <description summary="set surface title">
> -       Set a short title for the surface.
> +    <request name="state_unset_maximized">
> +      <description summary="unset the surface maximized state">
> +        Unset the surface as maximized.
>
> -       This string may be used to identify the surface in a task bar,
> -       window list, or other user interface elements provided by the
> -       compositor.
> +       The surface will be mapped to the corresponding state that has
> +       more precedence (e.g. if fullscreen is still set, the surface
> +       will be mapped as fullscreen, otherwise as a simple toplevel
> +       surface).
> +      </description>
> +    </request>
>
> -       The string must be encoded in UTF-8.
> +    <request name="state_set_fullscreen">
> +      <description summary="set the surface fullscreen state">
> +       Set the surface state as fullscreen.
> +
> +       If an output parameter is given then the surface will be made
> +       fullscreen on that output. If the client does not specify the
> +       output then the compositor will apply its policy - usually
> +       choosing the output on which the surface has the biggest surface
> +       area.
> +
> +       The client may specify a method to resolve a size conflict
> +       between the output size and the surface size - this is provided
> +       through the method parameter.
> +
> +       The framerate parameter is used only when the method is set
> +       to "driver", to indicate the preferred framerate. A value of 0
> +       indicates that the app does not care about framerate.  The
> +       framerate is specified in mHz, that is framerate of 60000 is 60Hz.
> +
> +       A method of "scale" or "driver" implies a scaling operation of
> +       the surface, either via a direct scaling operation or a change of
> +       the output mode. This will override any kind of output scaling, so
> +       that mapping a surface with a buffer size equal to the mode can
> +       fill the screen independent of buffer_scale.
> +
> +       A method of "fill" means we don't scale up the buffer, however
> +       any output scale is applied. This means that you may run into
> +       an edge case where the application maps a buffer with the same
> +       size of the output mode but buffer_scale 1 (thus making a
> +       surface larger than the output). In this case it is allowed to
> +       downscale the results to fit the screen.
> +
> +       The compositor must reply to this request with a configure event
> +       with the dimensions for the output on which the surface will
> +       be made fullscreen.
> +
> +       This state can be set while other surface states are still set,
> +       and it won't unset them. It has precedence over maximized, and
> +       the surface will be kept fullscreen until unset.
>        </description>
> -      <arg name="title" type="string"/>
> +      <arg name="method" type="uint"/>
> +      <arg name="framerate" type="uint"/>
> +      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
>      </request>
>
> -    <request name="set_class">
> -      <description summary="set surface class">
> -       Set a class for the surface.
> +    <request name="state_unset_fullscreen">
> +      <description summary="unset the surface fullscreen state">
> +        Unset the surface as maximized.
>
> -       The surface class identifies the general class of applications
> -       to which the surface belongs. A common convention is to use
> -       the file name (full path if non-standard location) of the
> -       applications .desktop file as the class.
> +       The surface will be mapped to the corresponding state that has
> +       more precedence (e.g. if maximized is still set, the surface
> +       will be mapped as maximized, otherwise as a simple toplevel
> +       surface).
>        </description>
> -      <arg name="class_" type="string"/>
>      </request>
>
>      <event name="ping">
> --
> 1.8.3.1
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel