<div dir="ltr">After a long weekend of not reading mails, I've read some mails; I'll try to make comments to everything in this reply.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 7:38 AM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey<br>
<br>
----- Original Message -----<br>
> On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:<br>
> > [...]<br>
> > If we considered and dismissed them, fine.<br>
><br>
> They are not "actively" considered in this patch, but as I mentioned<br>
> earlier, I think tiling states can later be added to the window state<br>
> enum.<br>
<br>
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.<br>
<br>
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 :)<br>
<br>
Cheers,<br>
Olviier<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a></blockquote><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div>** 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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div></div>