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.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
