Weston : ideas about xdg_sell, and implementation for a taskbar

[sardemff7+wayland at sardemff7.net]

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