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