Weston : ideas about xdg_sell, and implementation for a taskbar

[sardemff7+wayland at sardemff7.net]

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