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

[Jason Ekstrand]

Scott,
Allow me to be a bit more specific as to what I am thinking.  In
general, I like the requests and events in the protocol, I just think
things should be set out more clearly.  The documentation given in the
protocol isn't terribly specific as to how someone is supposed to
implement it.  From reading your code, it seems like you simply have
this magic "minimized" state that you're trying to keep in sync.
Unfortunately, it's not terribly clear.

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

In this way the client remains in control of what windows get
minimized etc.  I think it also makes it more explicit as to when a
window is/isn't max/minimized.  I also like this addition because it
allows for the possibility of server-side decorations.  Not that those
are going to be a for-sure thing, but allowing the compositor to relay
these kinds of events to the client is very useful.  Along these
lines, a "request_close" event is probably not a bad idea.  That said,
I think things should be client-controlled not compositor-controlled
as it leads to fewer edge-cases.

As far as use-cases go, I think there are a number of things to think about:
1. A window that does not want to be maximized.  What if the window
wants to have a fixed size?  Do you simply set it as maximized and let
it fail the configure event?  In that case the compositor thinks it's
maximized but, in reality, it's not.

2. A window that, when you minimize it actually minimizes other
windows as well (dialogues for example).  This is where Bill's example
falls.  If you want it more concrete, think about the original
multi-window layout of GIMP.  I don't want the dialogues visible
whenever at least one image window is visible and invisible when none
of the image windows are visible.  This could probably be handled in a
compositor-dictated system, but it will look strange if the image
window gets minimized and then, because of lag, the dialogue gets
removed a few seconds later.

3. A window that, when you maximize it, responds by maximizing
something else.  Consider a video player.  It may be using a
subsurface to display its video and then, when you press the maximize
button it actually detaches the video surface and sets it to
fullscreen.  Again, in a compositor-dominated environment this would
really confuse the compositor.

Hopefully this is concrete enough to demonstrate my point.

On Sun, Mar 17, 2013 at 9:02 PM, Scott Moreau <oreaus at gmail.com> wrote:
>>> I am not really sure what you are talking about but I'm also not sure I have
>>> time for it. The fact is that this is only a basic implementation to
>>> exercise the new protocol. If you would like to contribute code, the policy
>>> is that patches are welcome. A working implementation of what you think is
>>> better might also help to illustrate your points better.
>>
>> That's not really a good answer when we're talking about the core
>> protocol.  If this is so experimental, it should be added as a weston
>> extension, not to the wayland core.  Before we start adding things to
>> the wayland core protocol, we need to get it right.
>
> This series provides a complete example implementation in weston.
> Maximize and fullscreen are part of wl_shell_interface. It wouldn't
> make sense to put it anywhere else, than the same place as these
> existing events/requests.

Yes, it is an implementation.  However, I think there are some
corner-cases and things that need to be thought about.  Part of my
point above is that you can't blow off the people who review your code
with "I don't have time" and then expect Kristian to apply your
patches.  We need to be careful with the core protocol and make sure
we get it right.  There is a big limit as to how much of the
"implement it now and fix it later" we can do with the core protocol.
As soon as we have the 1.1 release, we (and the rest of the Linux
community) are stuck with it regardless of whether or not it's a good
implementation.

I hope that's more clear,
--Jason Ekstrand