[PATCH] xdg-shell: add draw states for xdg_surface

[Olivier Fourdan]

Hi Mike,

Thanks for posting this, perfect timing to discuss this in light of the tiling discussions ^_~

I reckon tiling and shadows can be related (even though one is an actual state, the other is a draw state).

For a bit of background on my comments below, see https://bugzilla.gnome.org/show_bug.cgi?id=766860

> this adds a method for compositors to change various draw attributes
> for a surface
> 
> Signed-off-by: Mike Blumenkrantz <zmike at osg.samsung.com>
> Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 69
>  ++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index dfd7e84..0fa76d4 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -843,6 +843,75 @@
>        </description>
>      </request>
>  
> +    <enum name="draw_state">
> +      <description summary="draw states for the surface">
> +        The draw state enum defines optional states which describe how
> +        a client should draw a surface. A client must at least support the
> +        default state, and support for optional draw states is explicitly
> +        advertised using xdg_toplevel.set_available_draw_states.
> +
> +        The default draw state implies that the client draws the surface
> +        with complete window decorations.
> +        This may include, e.g., window frame and drop shadow.
> +
> +        Each draw state defines an alteration to the default. Some draw
> +        states may be combined, while some are mutually exclusive. See
> +        each draw state for details.
> +
> +        Desktop environments may extend this enum by taking up a range of
> +        values and documenting the range they chose in this description.
> +        They are not required to document the values for the range that they
> +        chose. Ideally, any good extensions from a desktop environment
> should
> +        make its way into standardization into this enum.
> +
> +        The current reserved ranges are:
> +
> +        0x0000 - 0x0FFF: xdg-shell core values, documented below.
> +        0x1000 - 0x1FFF: EFL
> +      </description>

Do we really want reserved ranges here?

Some people reckon having (undocumented) reserved ranges was a bad idea in "states", I wonder if we should redo this here again.

Undocumented states from the reserved range are unlikely to be adopted by other desktops, and that might lead to duplication of similar mechanisms with different values.

> +      <entry name="no_shadow" value="1" summary="no dropshadow">
> +        <description summary="the surface without a dropshadow">
> +          The "no_shadow" draw state implies that the client must not draw
> +          drop shadow around the surface. This may have side effects
> +          on usability, e.g., the inability to activate client-initiated
> +          interactive resize.
> +        </description>
> +      </entry>
> +    </enum>

Is a single "no shadow" state enough, isn't that too restrictive? If we put this in perspective with a "tiled" state where we consider having tiled_left/right/top/bottom, similarly, we could have "no_shadow_left", "no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would give a finer granularity.

> +    <event name="configure_draw_states">
> +      <description summary="set the draw state(s) of the surface">
> +        Set the draw state(s) which the client should use to draw a given
> +        surface. The absence of this event prior to an xdg_surface.configure
> +        event indicates that no change has occurred in the draw state since
> the
> +        previous xdg_surface.configure.
> +
> +        Sending an empty array of states with this method resets a surface
> to the
> +        default draw state.
> +
> +        This event is not sent by itself but as a latched state sent prior
> to
> +        the xdg_surface.configure event. When received, a client should
> adapt
> +        the drawing of the surface according to the state and respond to the
> +        configure event accordingly. See xdg_surface.ack_configure for
> +        details.
> +
> +        A compositor will only configure a client to draw with optional
> states on a
> +        given surface using the states which were advertised by that surface
> using
> +        xdg_toplevel.set_available_draw_states.
> +      </description>
> +      <arg name="states" type="array" enum="draw_state"/>
> +    </event>
> +
> +    <request name="set_available_draw_states">
> +      <description summary="advertise optional draw states for the window">
> +        Inform the compositor of optional draw states which are available
> +        for the xdg_toplevel.
> +
> +        Calling this after an xdg_toplevel's first commit will raise a
> client error.
> +      </description>
> +      <arg name="states" type="array" enum="draw_state"/>
> +    </request>
> +
>      <event name="configure">
>        <description summary="suggest a surface change">
>  	This configure event asks the client to resize its toplevel surface or
> --
> 2.5.5

Cheers,
Olivier