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

[Jason Ekstrand]

Scott et. al,
I'm not going to try and answer everything because a lot has happened
on this topic and I think we're on the same page on most of the
technical details.


>> Here is how I think I would have such a protocol work. (Perhaps this
>> is what you intend, but, like I said, it's kind of hard to tell.)
>>
>> If the minimize event comes from compositor-side:
>> 1. The compositor sends a "request_minimize" event to the client (or
>> just "minimize", but I like the other a little better)
>> 2. The client responds with "set_minimized" events on any number of
>> top-level surfaces.
>> 3. The compositor minimizes the top-level surfaces as requested by the client
>>
>> If the minimize event originates client-side:
>> 1. The client sends calls "set_minimized" on any number of top-level surfaces
>> 2. The compositor minimizes the top-level surfaces as requested by the client>
>
>Yes, I completely agree. This is the same semantics of the current
>maximize implementation.

Ok, I think we're on the same page: The compositor gives the request
to the client -> client tells the compositor what windows need
changing -> compositor performs changes.

As far as frame callbacks go, like pq said, that's pretty much
orthogonal.  I think we should just let the compositor implementation
take care of that.  The point here is that none of this should get
implemented by the client removing the buffer from the surface in
order to unmap it.  That's unacceptable.  Instead, it should happen in
terms of modes.

There is one more question that I think needs to be answered.  And
that is: do we handle things in terms of set/unset or in terms of
set_maximized, set_fullscreen, set_minimized, and set_normal (probably
want a better name for that one).  Really, which of those two we do
doesn't matter that much because the toolkit can force it either way.
It's mostly a matter of who tracks the state and handles it.  I think
I like simply setting the state instead of keeping track of set/unset
better, but I'm open to discussion on that.

Assuming we can get the above question answered, I think I'd like to
see a version 2 with the following changes:

1. Clear and precise documentation.  If we're going to require a
client response to a minimize event, it needs to be well-documented.
2. Events for each of: request_maximize, request_minimize, and
request_close (The client should be able to handle fullscreen itself).
 I do prefer the request_x because it makes it more clear that the
compositor is requesting the client to minimize, not simply telling it
that it already is.
3. Some way for the client to unset maximized, minimized etc.
4. An enum and a request telling the compositor which of these
operations is supported.  This way the compositor can hide the buttons
or whatever.  The client can always ignore the request_x events, but
this provides a nicer UI.

Thanks,
--Jason Ekstrand