Weston : ideas about xdg_sell, and implementation for a taskbar
spitzak at gmail.com
Mon Feb 10 12:57:27 PST 2014
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
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.
More information about the wayland-devel