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.
