Weston : ideas about xdg_sell, and implementation for a taskbar

[Bill Spitzak]

sardemff7+wayland at sardemff7.net wrote:

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

I was thinking the compositor would need the parent information. For 
instance if may show one taskbar entry per minimize request. But there 
may be other methods of doing this.

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

Okay this is an interesting method for making atomic minimization 
without having to send a parent tree to the compositor.

My main concern is that I think the parent tree is going to be needed 
anyway so I'm not sure this adds anything.

Also I am unsure how a client indicates which minimize is the "main" 
one, as the compositor can't tell if another minimize is coming. This is 
a problem even for compositor-generated minimizes as the client may want 
to respond to a minimize request in a dialog box by minimizing the 
entire application, not just the dialog box.

> I mean “unfocus”. There is no reason to treat the minimized with a
> special event. The client already reparented surfaces and raised
> everything relevant.

As long as the client is in charge of mimimizing itself (which it now 
sounds like you are proposing and is exactly what I was trying to 
propose originally) then this is ok.

In fact the client could even assume that it loses the focus so no 
unfocus event is needed (but it appears a Wayland design criteria is to 
ensure pairing of events so it should be sent, though IMHO this enforced 
pairing is a waste of time as no sane client will rely on it).

A surface without focus can be minimized, it's just that the client will 
be unable to tell if it worked.

It is true that a client may display incorrect graphics if the 
set_minimized is ignored. If it expects an unfocus it could detect this 
after a delay but even then the drawing will blink. But I don't think 
this is a major concern.

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

Okay, that sounds exactly like what I proposed, which is the client is 
in final control over the minimization. Nothing happens until the client 
sends the set_minimized request. I definately prefer this but I must 
have misread your description as it sure sounded like you wanted 
communication after the compositor minimized the window, not before.