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

[Bill Spitzak]

Scott Moreau wrote:

> "Further, the term minimize is relatively subjective and defined by the
> implementation. Clients should not expect that minimized means the surface
> will be invisable to the user. There are several use cases where displaying
> minimized surfaces will be useful."
> 
> Minimize can be handled differently by each compositor. The protocol 
> does not define minimize explicitly. The important part is that the 
> protocol is in place so that the compositor and clients can communicate 
> minimize state information, not unlike maximize. The comment you're 
> looking at does not represent any protocol restriction, it's merely a 
> reminder that suggests a minimize surface might not be unmapped. We 
> might want to view 'live' minimized surfaces in a window preview, 
> graphical window switcher or scaling feature. It seems that you're 
> misinterpreting this specific text but I'm not really sure what you 
> mean. Just know that the weston implementation is a reference with 
> working proof-of-concepts, exercising and demonstrating the protocol. A 
> different wayland compositor can handle all of these events and requests 
> differently.

Actually perhaps I am misunderstanding it. Does it just send an "unmap 
request" from the shell to the client? From the code it seems to cause 
the compositor to stop showing the minimized window without any 
indication being sent to the client at all, which I absolutely disagree 
with!

If in fact the window will not vanish until the client responds to the 
unmap request, that will allow the client to atomically unmap child 
windows if wanted.

I'm not sure if that is a good idea to have the "unmap request" without 
an indication that it is due to a minimize, though. Maybe there are 
multiple reasons for an unmap request and clients may want to respond 
differently to them.