[PATCH] wl_shell: Add surface state changed event

[Mikko Levonmaa]

On Wed, May 15, 2013 at 01:57:10PM -0500, Jason Ekstrand wrote:
> On Wed, May 15, 2013 at 1:37 PM, Mikko Levonmaa <mikko.levonmaa at gmail.com>
> 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 <mikko.levonmaa at gmail.com
>     >
>     > 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