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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to