Weston : ideas about xdg_sell, and implementation for a taskbar
sardemff7+wayland at sardemff7.net
sardemff7+wayland at sardemff7.net
Mon Feb 10 13:44:07 PST 2014
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
> 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.
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.
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.
> 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
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!).
Quentin “Sardem FF7” Glidic
More information about the wayland-devel