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

[Bill Spitzak]

Scott Moreau wrote:

 > I don't know what you're talking about here but please see the comment
 > in the last paragraph of the commit message:
 >

The concern is exactly the same as for any subsurfaces and for child 
floating windows.

The specific example is a client has any number of "main" surfaces and a 
single "toolbox" floating above it. Assume the toolbox should disappear 
if and ONLY if all the "main" surfaces are minimized.

I assume you are intending a solution that works for the case of one 
"main" surface. This would be done by an additional client api to 
indicate that the toolbox is a "child" of the main surface, and the 
shell would know to unmap all the "children" when the main surface is 
minimized.

Now what to do if there are two "main" surfaces? If the toolbox is a 
child of the one you close then it will vanish. If it is not a child of 
any then it won't vanish even if you close both, plus it will show up in 
the panel.

The only solution is to convey an entire directed acyclic graph of 
window descendents from the client to the compositor. This would be 
*fiendishly* complex due to the need of the client to be able to make 
arbitrary changes in an atomic way combined with the creation, 
destruction, and reordering of surfaces. I do not think there is a 
workable method other than dumping the entire new DAG as a single 
request (as computing a non-blinking minimum set of changes from one DAG 
to another is impossible). There are also really annoying problems with 
making the changes atomic with the changes of contents of windows so 
that at no moment does the user see incorrect window contents different 
than the current stacking order.

It is instead trivial for the client to just receive a "minimize" event 
and respond by unmapping the main window and the toolbox if it is the 
only main window. This is extremely reliable and easy.

I do propose that the client be able to send a "tree" of window 
relationships to the compositor (a tree is different than a DAG as there 
is at most one path from one node to another). This is simpler for two 
reasons: it can be updated reliably with single atomic "change the 
parent of x to y" calls, and second because I want the changes to have 
no effect on the window stacking or appearance (the clients are expected 
to fix this to match as they update the tree). The tree is useful for 
the panel and similar third party programs to introspect the setup of 
surfaces, that is it's only purpose.

> "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."

This would be supported by having the "minimize request" *not* send a 
"minimize event" from the compositor to the client. If the result is 
something other than "minimize is ignored" then it would send a 
different event describing the desired result.

Really I find it hard to believe a design that requires knowing whether 
the desktop or tablet shell is being used would have problems with the 
client also knowing what type of minimize the shell is using.