Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Mon, Jul 08, 2019 at 04:43:28PM -0400 I heard the voice of
Stefan Monnier, and lo! it spake thus:
> 
> 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.

The short version is that the end result of my mental traipsing
through the cases was a conviction that we needed to track a base
prioritity (the things the user set via OnTopPriority{} or
f.*priority), and a set of adjustments on top of that (what EWMH
messages and fullscreen status set).  Trying to just have those
messages/stati change the stored priority turned into a mess of
double-applying or double-removing, because (among other issues) we
never find out about EWMH _transitions_, only _current states_.  So if
e.g. we get told a window "is _ABOVE", but nothing tells us whether
that's new, or it was _ABOVE before already.  We'd have to track all
that stuff and hope to get it perfectly right.  By tracking base +
alterations = effective, we can always just blat the current state
into alterations, and know the end result will be right.

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 suspect we actually can have similar problems with _ABOVE/_BELOW
stuff, but since that's not focus-dependent, and probably not
particularly dynamic, we never see it triggering.  So a broader fix
will need to address that too.  Actually, I vaguely think a broader
fix could potentially move us back to just being able to Restack even,
but I haven't experimented toward that yet.  I'm still hoping we can
make a targetted fix to this focus-shifting variant that's easy-ish to
trigger, and backport to a point release.



> I don't understand how that spec says that focus changes should
> change stacking order.  It doesn't seem to say anything about what
> we should with FULLSCREEN windows that don't have focus, so it seems
> perfectly acceptable to keep them on top.

I don't think so.  For one, even if we go with that reading, it means
that as soon as a window is fullscreen we can never pull up anything
over top of it; that wouldn't be friendly.  But I don't think that's
the best reading of it anyway.  To reproduce the whole:


>    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.  That is, if
you've got one _FULLSCREEN window, and one _ABOVE, then if the
_FULLSCREEN one is focused it should be above the _ABOVE, but if
anything else is focused, the _ABOVE should be above the _FULLSCREEN.



-- 
Matthew Fuller     (MF4839)   |  [email protected]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.