[PATCH] xdg-shell: add draw states for xdg_surface
gschwind at gnu-log.net
Tue Jun 7 09:34:14 UTC 2016
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.
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.
More information about the wayland-devel