[PATCH] wl_shell: Add surface state changed event

[Jason Ekstrand]

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130515/d7f9fe31/attachment.html>