Weston : ideas about xdg_sell, and implementation for a taskbar

[Bill Spitzak]

Okay this sounds like it is going in exactly the wrong direction.

What I am trying to do is restore the ability to use overlapping windows 
which was broken in approximatly 1990 when everybody started doing 
"click raises" (when even then it was *trivial* for a client to raise 
it's own windows), and has only gotten worse as "roles" and "layers" and 
so on have been added so that we can no longer even know if the user 
will be able to close a dialog box or whether it is visible when we 
don't have the focus.

Current schemes are about as useful as the compositor drawing into your 
surface automatically in response to various mouse clicks (like always 
drawing a line on the assumption that you are a sketching program), then 
claiming you can "fix" it by drawing the correct picture again 
afterwards. This is obviously nonsense but for some reason the same 
logic is not being applied to surfaces.

All I want is for the client to have final say over exactly what 
surfaces are visible and what their stacking order is. Then we may be 
able to implement floating dialog boxes again after 25 years of the dark 
ages.

This means that no surface disappears, appears, or changes stacking 
order until after the client has been allowed to adjust all the other 
surfaces it owns.

And that means there cannot be a "you were minimized" event. There can 
only be a "I want you to minimize" event. It also means that a request 
from the client to be minimized must be obeyed.

The compositor is allowed to detect "dead" clients (and misbehaviong 
clients) and fake anything it wants, but this should not be used to 
dictate the api. The api should be designed and described for 
well-behaved clients (with perhaps a few notes on things that a 
compositor can detect that tells it that the client is behaving badly 
enough that the api should be ignored).

Manuel Bachmann wrote:
> Agreed ; it makes a lot more sense this way.
> 
> BTW, I'm not sure we *really* need to add things to xdg-shell. We'd just 
> need it if we want to have client-side logic. A pure server-side logic 
> just needs modifications in desktop-shell.
> 
> I think my question is really what a Weston implementation should do.
> Currently, the code can do it both ways.