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

[Benoit Gschwind]

Hello Olivier,

On 07/06/2016 11:15, Olivier Fourdan wrote:
> Hi Benoit,
> 
> ----- Original Message -----
>> On 07/06/2016 10:30, Olivier Fourdan wrote:
>>> [...]
>>> I disagree here, if anything we should keep the semantic states separate,
>>> we wouldn't want to have something like "no_shadow" or "no_border" as a
>>> semantic state like "maximized" or "fullscreen", do we?
>>
>> fullscreen and maximized are shortcut for drawing states:
>>
>>  * fullscreen = no_border+no_shadow
>>  * maximized = no_shadow+no_maximized_button+reduce_button
>>
>> what about activated state, that basically mean draw it as activated ?
> 
> No, a window being "active" remains true independently of the compositor running, whereas the "draw states" are a way to negotiate between the compositor and the application which one would be drawing some of the decorations/controls.

are we reading the same specification? citation: (xdg-shell-unstable-v6.xml)

<entry name="activated" value="4" summary="the surface is now activated">
        <description summary="the surface is now activated">
          Client window decorations should be painted as if the window is
          active. Do not assume this means that the window actually has
          keyboard or pointer focus.
        </description>
</entry>

The active state is a state that the compositor choose, and they do not
remain if there is no compositor.

> 
> A compositor may wish apps to be without drop shadow no matter the state, active, fullscreen, maximized, tiled or other. 
> 

The state activated can be applied to fullscreen, maximized or tiled,
exactly as without_shadow.

>> This is too difficult to draw a line between draw states and "behaviors"
>> states, they are linked.
> 
> The semantic states imply a well commonly accepted presentation (like fullscreen, all window controls are hidden), but the opposite isn't true, it's impossible to deduce a state from just the presentations flags.

Which level of complexity have to be a semantic state to be a /semantic
state/: see activated state above.

>> I think we should think about window state once more :D
> 
> I reckon the current states as defined in xdg-shell are commonly understood, established and accepted between environments, I don't see the need to change that.
> 

Same here, I do not want change current states, just add some.
I prefer this than using a work-around to avoid decision policy.

> Cheers,
> Olivier
> 

Best regards
--
Benoit Gschwind