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

[Derek Foreman]

On 31/05/16 02:31 PM, Benoit Gschwind wrote:
> Hello mike,
> 
> Thank for your clarification, I try to summarize the issue/need:
> 
> A compositor may want to draw a client without the shadow. In particular
> if the window is integrated to a GUI component, I can imagine tilling.

Tiling seems only tangentially related to this proposal, since it's just
one reason why a compositor might want to turn off drop shadows.

> Taking your issue, the drawing state look very similar to the state
> flags. You wrote: "[the draw state is] specifically related to drawing
> only". Actually, removing the shadow may have side effect related to
> behavior, in particular for client that use shadow as resize handlers,

The spec mentions that removing the drop shadow may interfere with
interactive resize - from my reading it seems the intent is just to tell
the client not to render drop shadows (not to draw something else in
their place).  Perhaps that could be clarified in the next revision.

> those client may replace shadow by plain borders. In that case the
> difference is very thin. In the oposite way, the most expected changes
> of fullscreen or maximized state is the client layout.
> 
> You wrote: "[the draw state has] negotiation", I agree, but I will use
> the wording "hint" because look more appropriate. Why do not add state
> hint ? Some will argue that state are mandatory, to that I reply: ok,
> how do you enforce it? You have no way to check that a client do not
> draw a shadow while maximized or in fullscreen state, or basically
> ignore the state. Thus just consider that those mandatory hints are
> always included. States hints are similar to EWMH [1] or the WM_PROTOCOL
> of ICCCM.

I'm not sure I understand your point, but I think you just successfully
shot it down yourself?

Moving right along then... ;)

Indeed states are mandatory and the compositor has to assume they've
been obeyed - any app that doesn't is buggy.  Adding optional behaviour
to that mechanism seems like a really bad idea.

The negotiated method presented here seems less bug prone, and allowing
toolkits not to have to implement all states seems less onerous.

PS: When we're done re-inventing EWMH for wayland, can we have xatoms
too?  Hmm, maybe not everything from the old days needs a direct mapping
to wayland. :)

Thanks,
Derek

> About the state enum, you are correct, the current spec. has reserved
> ranges. My opinion still the same, this ranges are basically anti-standard.
> 
> Best regards.
> 
> [1]
> https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472593792
> 
> On 31/05/2016 17:40, Mike Blumenkrantz wrote:
>> After a long weekend of not reading mails, I've read some mails; I'll
>> try to make comments to everything in this reply.
>>
>> On Tue, May 31, 2016 at 7:38 AM Olivier Fourdan <ofourdan at redhat.com
>> <mailto:ofourdan at redhat.com>> wrote:
>>
>>     Hey
>>
>>     ----- Original Message -----
>>     > On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:
>>     > > [...]
>>     > > If we considered and dismissed them, fine.
>>     >
>>     > They are not "actively" considered in this patch, but as I mentioned
>>     > earlier, I think tiling states can later be added to the window state
>>     > enum.
>>
>>     Just a quick note before my main power source goes down here, my
>>     comment are not about tiling, as stated before, I just tool tiling
>>     as an example of where we eanted to have a value per edge.
>>
>>     FWIW, I don't think tiling is a "draw state", I reckon it's a plain
>>     state just like "maximized" or "active". But tiling is worth its own
>>     thread :)
>>
>>     Cheers,
>>     Olviier
>>     _______________________________________________
>>     wayland-devel mailing list
>>     wayland-devel at lists.freedesktop.org
>>     <mailto:wayland-devel at lists.freedesktop.org>
>>     https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>
>> * Range allocations were added only because it was created in a similar
>> way to the configure state enum, which has such allocations. I don't
>> care much about them and I had no plans to use them at this time.
>>
>> * This patch is solely about implementing the basic idea of "draw
>> states"--a method for negotiating and controlling the manner in which
>> the client draws its windows. I don't see a need to "define the issue"
>> further than "this is a new display server protocol, let's ensure
>> there's a standard way to negotiate/control drawing between the server
>> and clients". This is clearly different from window states due to 1)
>> negotiation, and 2) specifically related to drawing only, not behavior.
>> ** The initial value of "no shadow" exists because it's a useful thing
>> to have in some cases (e.g., flat ui theme in compositor+toolkit,
>> compositor wants to draw special shadow effects, ...) and is not
>> controversial--moreover, it's trivial to implement compared to other
>> potential states.
>>
>> The concept of draw states is easy to envision extensions for when
>> provided with this base example, and these extensions can be discussed
>> at a later time and in a separate thread if everyone can agree on the
>> premise. A tiled state is certainly something worthwhile to consider at
>> that time and place.
>>
>>
>>
>>
>>  
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>