>> Looking at OwlEffectivePriority which in my code was just a access
>> to the owl->priority field, I see that the priority is now a lot
>> more dynamic, so there's indeed a lot more ways to change the
>> priority and forget to adjust the stacking accordingly.
>
> Yeah. This came out of a apparently minor issue with EWMH stuff
> overriding config file set priorities, which on investigation
> ballooned into a giant mess of fitting dynamic EWMH state into the
> system. X-ref back the "AlwaysOnTop xclock" thread, in Jan-Apr 2017.
Yes I remember. The new code makes a lot of sense.
> But, yeah; it does mean that things can change much more implicitly.
> So, best I can tell, we wind up needing to add more explicit OTP calls
> than just "Restack window to where it looks like it currently should
> be". Thus, OtpFocus/Unfocus in my patch; that lets us get enough info
> about what's happening into the OTP-understanding layers for them to
> DTRT.
I must admit that I don't understand why "restack window to where it
looks like it currently should be" isn't sufficient (assuming you cann
this "restacking" after setting the focus info, which implicitly
changed the destination otp target layer).
>> windows of type _NET_WM_TYPE_DESKTOP
>>
>> windows having state _NET_WM_STATE_BELOW
>>
>> windows not belonging in any other layer
>>
>> windows of type _NET_WM_TYPE_DOCK (unless they have state
>> _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE
>>
>> focused windows having state _NET_WM_STATE_FULLSCREEN
>
> Since it never lists "*un*focused [...] _FULLSCREEN" anywhere, it
> implicitly says they should go into the third layer.
So if the focus is currently on a transient window of a FULLSCREEN
window, that FULLSCREEN shouldn't be above the ABOVE windows?
Stefan
