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

[Benoit Gschwind]

Hello Jonas,

I understand your point, and also we bike-shedding. if you add
not_shadowed state to the state list you solve the first part of the
issue. I do not think we need more states list.

Next issue is to how advertise to the compositor which optional states
are supported by the client. In that case your proposal is fine:
set_available_states. Maybe it could be client wide, but the per surface
is fine.

I don't think adding a separate state list help to make it accepted. For
me adding those list, look like saying: "your are reluctant to add state
to the state list, thus I create a new list, it's better isn't it ?"

This is my opinion.

Best regards.

On 07/06/2016 10:59, Jonas Ådahl wrote:
> On Tue, Jun 07, 2016 at 10:47:13AM +0200, Benoit Gschwind wrote:
>> Hello Olivier
>>
>> On 07/06/2016 10:30, Olivier Fourdan wrote:
>>> Hi Benoit,
>>>
>>> ----- Original Message -----
>>>> [...]
>>>>
>>>> My primary complain is that draw states should be merged with the
>>>> previously defined window/surface states, because by definition a draw
>>>> state is a state for a window, just like the state activated for example.
>>>
>>> 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 ?
>>
>> This is too difficult to draw a line between draw states and "behaviors"
>> states, they are linked.
>>
>> I think we should think about window state once more :D
> 
> The point is to separate semantical states, where the interpretation of
> how the state translates into how a client draws its content is mostly
> up to the client itself, from draw states, which more strictly defines
> what exactly is different and whether the responsibility of drawing
> those parts may or may not be moved from the client elsewhere.
> 
> For example, fullscreen is not "no border + no shadow", it may involve
> various other things, and we are not going to define all those things in
> a gigantic state enum when the end result for the compositor is all the
> same.
> 
> 
> Jonas
> 
>>
>>> Cheers,
>>> Olivier
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>
>> Best regards
>> --
>> Benoit Gschwind
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>