[PATCH wayland v3] protocol: Add minimize/maximize protocol

[Jason Ekstrand]

On Mon, Mar 25, 2013 at 12:24 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Jason Ekstrand wrote:
>
>> One more thing before I go onto the technical details: Bill Spitzak.
>> Just because he gets on your nerves doesn't mean you should just
>> ignore him.
>
>
> Thanks but I think my email was pretty rambling and I should not have sent
> it. Can try to say what I wanted in a *short* way:
>
> A surface can be both "minimized" and "maximized" at the same time, ie it
> looks minimized but when un-minimized it then looks maximized. I thought it
> might be necessary for both the client and the compositor to know this, and
> thus a set of on/off flags sent as a batch would be the best way to
> communicate this. A sequence of on/off command for each flag would have
> annoying bugs if the two ever got out of sync.
>
>
>> Thanks for your comments Bill!  I have thought about this solution and
>> I think it would work fairly well if we were to have the client send
>> an explicit next state such as minimized, maximized, or normal to the
>> compositor.
>
>
> I think you may be right that the compositor does not actually need to know
> the set of states, so there is no problem with bugs making the compositor
> and client disagree, which was the primary reason I thought sending the
> entire set of states at once was a good idea.
>
> This will require the compositor to send an un-minimize event, though, since
> it does not know if the result will be normal or maximized or fullscreen. My
> main concern is now the enumeration of possible messages is now larger than
> the number of states since it has to include these "un-state" messages.

Perhaps It would help if I explained the framework in which I'm
thinking about the problem.  Imagine either a window list or a
server-side decorations setup.  In either case, the server needs to be
able to tell the client that the user is requesting a state change.

Now we have two orthogonal concepts to manage: the user's request to
change the state and the client telling the compositor what state to
change.  These do not have to act the same in any way.  The important
thing is that the compositor tells the client what was requested and
the client responds by telling the compositor what to do.

For the client instructing the compositor what to do with its windows,
I think simply setting the state it wants is probably the best option.
 Otherwise, there is a lot of state tracking involved and it just
makes the protocol more complicated.  When it comes to the requests
made by the user, I think they need both state and un-state forms.  If
we want to keep the client in control, the compositor should never
simply tell it what state to enter.  Also, the client is liable to
change the state of any of its windows without direct interaction from
the user.

There is one other little issue: what options do you present to the
user at any given time?  However, I think we can get around this issue
without too much trouble.
--Jason Ekstrand