On 10/02/2014 21:57, Bill Spitzak wrote:
Okay this sounds like it is going in exactly the wrong direction.
And you sound like you do not understand the strong need here: the
compositor *must be in charge* of everything. But, please, do not start
to yell now, it can perfectly work well with your need as well, let me
explain.
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.
That sounds ok to me.
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.
Partly wrong.
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.
Second, the client must define relations between its surfaces, we both
agree on that and I am pretty sure everyone does agree to some extent.
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.
True.
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).
No. It *must* have a properly defined behaviour for all cases *that will
keep the compositor in charge*. The compositor is also the shell, and
the shell is user’s choice because it implies a policy that the user wants.
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]
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]
3. Only ever use “toplevel” (= no parent) surfaces compositor-side for
the .request_set_minimized [client surfaces relations]
4. Have a way for the client to know which features are supported
[client UI consistence]
IMO, the same points (adapted) apply to all features that may have UI
both client-side and compositor-side.
Concerning point 4, it could be a decoration flag in the configure
event, the same way we want side ones (to support tiling!).
Thanks,
--
Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
