Weston : ideas about xdg_sell, and implementation for a taskbar

[Bill Spitzak]

sardemff7+wayland at sardemff7.net wrote:

> First, a compositor may have no mechanism of “minimization”, so it must 
> not be forced to obey such a request with no meaning for it.

I agree the compositor does not have to obey the minimize request. I 
think I am not explaining things clearly: *BOTH* the client and 
compositor must decide to minimize or it does not work.

You may be right that the client needs to know it won't work.

> Based on Bill’s events and requests, here is what I think should handle 
> all cases the right way while keeping the global policy on the 
> compositor’s side [in square brackets, the part(s) that the point ensure]:
> 1. States that the client *must* call .set_minimized at least on the 
> same surface as the .request_set_minimized [compositor policy, client 
> surfaces relations]

Yes I think that is a way to detect dead clients.

Rather than send minimize on many surfaces I propose the client arranges 
all the windows it wants to vanish as children of each other and then 
sends the minimize request to the top one (the one that the compositor 
requested must either be this top one or in the list).

Multiple minimizes can then mean that the client wants multiple taskbar 
entries or that unminimizing one window is different than the other.

> 2. Do not assume anything (e.g. do not draw “inactive” window borders) 
> before the real events (frame callback, focus events and friends) 
> [compositor relevant features]

This will not work. The actual vanishing of the minimized window must be 
deferred until *after* the client has done this, or it will not be atomic.

> 3. Only ever use “toplevel” (= no parent) surfaces compositor-side for 
> the .request_set_minimized [client surfaces relations]

Not sure why you want to limit it like this. I certainly would like the 
ability to minimized dialog windows.

> 4. Have a way for the client to know which features are supported 
> [client UI consistence]

You may be right that the client does need to know if the compositor 
would obey the minimize. I thought it was not a problem but as you point 
out the client may redraw the activation or move things around on the 
assumption that it is going to work.

My first thought is to make this a 3-way communication. If you hit a 
minimize button the client sends a minimize-request-command to the 
compositor. The compositor then responds with a minimize-request-event. 
The client then knows it is going to work, adjusts all it's display, and 
sends a minimize-command.

It may be better to just have an event that says whether the compositor 
will obey things, like you suggest.

ALTERNATIVE:

Actually after I typed this I think there may be a scheme that works 
more like you want but I'm not sure if it is practical:

1. Client sends a minimize-request on a surface, or the compositor just 
decides to minimize a surface.

2. Compositor sends a minimize-notify (or not if it does not want to 
minimize). However (here is the tricky part) the surface has not really 
minimized! It is still visible on-screen and everything works as before 
until the compositor sees a commit that it knows is in response to the 
minimize-notify.

3. Client then can respond to the minimize-notify by rearranging the 
surface tree, redrawing surfaces, doing minimize-request on other 
surfaces, etc. It then eventually does a commit, and the serial number 
can be used to identify that it is in response to the minimize-notify 
(is this possible in wayland?). Note the client is unable to stop the 
surface from minimizing, but can get ready for it.

4. If the client is dead then the compositor just does the minimize 
using the current surface parent/child tree.