On Wed, May 15, 2013 at 01:57:10PM -0500, Jason Ekstrand wrote: > On Wed, May 15, 2013 at 1:37 PM, Mikko Levonmaa <[email protected]> > wrote: > > On Wed, May 15, 2013 at 12:12:43PM -0500, Jason Ekstrand wrote: > > On Wed, May 15, 2013 at 9:39 AM, Mikko Levonmaa > <[email protected] > > > > wrote: > > > > This allows the shell to inform the surface that it has changed > > state, current supported states are default, minimized, maximized > > and fullscreen. The shell implementation is free to interpret the > > meaning for the state, i.e. the minimized might not always mean > > that the surface is fully hidden for example. > > > > > > We cannot simply have the shell telling clients it changed their state. > > The > > clients need to be in control of the state of each surface. This is > because > > minimizing a client (for example) might not be as simple as hiding a > specific > > window. Only the client can actually know how to minimize/maximize it. > > Hmm... not sure I fully understand nor agree (perhaps lack of > understanding;). So to me it seems that the compositor should be the > driver, not the passenger, i.e. it know how to animate the surface when > it gets minimized and when maximied. How would the client know this? > Also wouldn't this imply more knowledge on the toolkits side as well? > > > 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.
Right, true. I initially misunderstood what you ment with "Only client can actually know..." > There are a lot of other possible scenarios and the compositor can't know what > to do there. > > > > > Please read earlier min/max discussions or yesterday's IRC logs for more > > details. > > Neato, seems to be a hot topic, good to see someone else looking into > this as well. I read through the email and pq's commmets about avoiding > flicker > make sense, so having the compositor and the client be in sync about whats > going on is needed. Also naturally the client can be the originator, so > clearly a request is needed. However in some cases the request might not > be > honored by the compositor, especially in an embedded environment. And > actually also the compositor might only show window only in certain > state, i.e. fullscreen so having the client full to decline a request > might not be good either. > > > 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. Why would we want the fullscreen compositor use a different shell interface? This would force the toolkits to have different implementations for various compositors/WMs, granted that some of them already do, but still to me it seems like a step in a wrong direction. I would much rather see that the wl_shell interface serves them all and the implementations of that interface might behave differently. Not saying that the wl_shell should be a god like interface, but I think that there is enough common ground. > For more information, you can also read this e-mail thread. Be ware, there is > a lot of noise in it: > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > > --Jason Ekstrand _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
