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

[Benoit Gschwind]

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.

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,
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.

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.
> 
> 
> 
> 
>