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

Mon May 30 10:21:12 UTC 2016

On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
> 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.

The purpose of a private range is not to have its values adopted by
other desktop environments, but rather a place to put experimental
things or things that might not suite a proper documented state. The
ranges is intended so that different DE:s don't conflict.

I don't see what is wrong with that.

The alternative is to have a separate configure event in an extension.
It would work the same way, is a bit more code to write, but it'd
effectively result in the same problem.

> 
> > +      <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.

I think we should just add such tiling states to the window state enum,
rather than the draw state. The only point with putting things in the
draw state enum is to get the negotiation, while tiled vs not tiled is
closer to maximized vs not maximized, i.e. a compositor wouldn't change
its behaviour if the client couldn't not draw itself "tiled" or not.

As discussed in the bug you linked, there might be more to tiling than
shadow as well; it might effect rounded-ness of corners and maybe other
things as well, and adding "no_shadow_right" wouldn't address that.

Jonas

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