<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 15, 2013 at 1:37 PM, Mikko Levonmaa <span dir="ltr"><<a href="mailto:mikko.levonmaa@gmail.com" target="_blank">mikko.levonmaa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Wed, May 15, 2013 at 12:12:43PM -0500, Jason Ekstrand wrote:<br>
> On Wed, May 15, 2013 at 9:39 AM, Mikko Levonmaa <<a href="mailto:mikko.levonmaa@gmail.com" target="_blank">mikko.levonmaa@gmail.com</a>><br>
> wrote:<br>
><br>
> This allows the shell to inform the surface that it has changed<br>
> state, current supported states are default, minimized, maximized<br>
> and fullscreen. The shell implementation is free to interpret the<br>
> meaning for the state, i.e. the minimized might not always mean<br>
> that the surface is fully hidden for example.<br>
><br>
><br>
> We cannot simply have the shell telling clients it changed their state. The<br>
> clients need to be in control of the state of each surface. This is because<br>
> minimizing a client (for example) might not be as simple as hiding a specific<br>
> window. Only the client can actually know how to minimize/maximize it.<br>
<br>
</div>Hmm... not sure I fully understand nor agree (perhaps lack of<br>
understanding;). So to me it seems that the compositor should be the<br>
driver, not the passenger, i.e. it know how to animate the surface when<br>
it gets minimized and when maximied. How would the client know this?<br>
Also wouldn't this imply more knowledge on the toolkits side as well?<br></blockquote><div><br></div><div>The clients don't need to know any of that. The client tells the compositor "minimize this surface" and the compositor animates it. Sure, the compositor has to know what's going on, but that doesn't mean it needs to be the driver. Also, the compositor doesn't know what all else needs to happen. For instance, let's say that gimp wants to run in multi-window mode most of the time but destroy the dialogues and go to single-window mode when you maximize it. How would the compositor know what windows need to go where? Only the app can know that.<br>
<br>There are a lot of other possible scenarios and the compositor can't know what to do there.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><br>
> Please read earlier min/max discussions or yesterday's IRC logs for more<br>
> details.<br>
<br>
</div>Neato, seems to be a hot topic, good to see someone else looking into<br>
this as well. I read through the email and pq's commmets about avoiding flicker<br>
make sense, so having the compositor and the client be in sync about whats<br>
going on is needed. Also naturally the client can be the originator, so<br>
clearly a request is needed. However in some cases the request might not be<br>
honored by the compositor, especially in an embedded environment. And<br>
actually also the compositor might only show window only in certain<br>
state, i.e. fullscreen so having the client full to decline a request<br>
might not be good either.<br></blockquote><div><br></div><div>Clients can *always* misbehave. Suppose a client gives the wrong size surface when it goes maximized. Or that it doesn't get rid of its window shadows around the sides. Since the client is drawing itself, it can always misbehave. Yes, there are cases where the compositor would want to run everything fullscreen. However, those wouldn't be desktop compositors. a fullscreen-only compositor would probably be a different interface than wl_shell. No one has really put a lot of time or effort into non-desktop compositors as of yet.<br>
</div><div> <br></div><div>For more information, you can also read this e-mail thread. Be ware, there is a lot of noise in it:<br><br><a href="http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html">http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html</a><br>
<br></div><div>--Jason Ekstrand<br></div></div></div></div>