On 11/02/2014 02:23, Bill Spitzak wrote:
May not have explained it correctly. It sounded like you were not going to allow dialogs to be minimized except as a side-effect of minimizing the parent.
I was, but I am not any more.
I certainly want to allow this! And I certainly want to support minimizing multiple surfaces.
I agree, it is needed.
I was suggesting that one method of minimizing multiple surfaces would be for the client to arrange them all as children of one of them and then minimize the parent. The primary purpose is so the compositor/taskbar knows all those windows are "related", for instance to produce on a single taskbar entry.
All scenarii are supported. You can reparent or simply minimize everyone.
No, because if the client wants to redraw or raise or show or hide any other surface as a side-effect of the minimize, these changes will not be atomic with the minimize, resulting in unwanted flickering of an intermediate display. There has to be a way for the minimized window to not disappear until the client does some kind of commit.
The commit *is* the .set_minimized. You can raise, draw everything you want *then* send the .set_minimized request. It is the last step of the minimization process. In the scenario of multiple .set_minimized requests, the last one must be the “main” one (either the one requested by the compositor or the one triggered by client UI).
I assume you mean "minimize", not "unfocus"? It must be possible to minimize windows that don't have focus.
I mean “unfocus”. There is no reason to treat the minimized with a special event. The client already reparented surfaces and raised everything relevant.
It sounds like you are describing the 3-way communication I proposed. I see 3 steps: 1. Client decides it wants to minimize, tells compositor (this step is not done if the compositor chooses to do so). 2. Compositor tells client that the minimize is happening. 3. (the step you are missing) client tells compositor it has corrected all it's surfaces to reflect the result of minimizing and it is ok to perform it.
No, I am describing a .request_set_minimized/.set_minimized use case: 1a. The compositor send the .request_set_minimized event. 1b. The client “minimize” button is pressed. 2. The client reparent, draw, raise, do whatever it needs to keep the UI consistent. 3. The client send the .set_minimized request. 4. The relevant surfaces are hidden by the compositor. In case 1b with a compositor not supporting minimization, the client will just looks a bit weird. But: 1. I believe that a user will not expect anything better when using such a compositor. 2. Using flags in the configure event to inform the client which actions are supported will just remove such a weird case.
[…]
The rest of your email should be answered already. Thanks, -- Quentin “Sardem FF7” Glidic _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
