>> Hmm... so is it because we changed PRI(owl) without changing the >> OtpWinList accordingly, [...] > > Yes[0]. The PRI() of the transient changed when the main window > gained focus, but it's still down among the normal windows where it > was prior.
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. >> I missed this change. I'm not very familiar with FULLSCREEN. Why >> do we need to change the OTP depending on focus? > https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER > > * [on the top of everything] focused windows having state > _NET_WM_STATE_FULLSCREEN 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. To my naive reading, I'd argue that we should raise windows to the foreground when they get the FULLSCREEN prop and disregard focus. Of course, that shouldn't make any significant change to the code anyway: when we get a property change to/from FULLSCREEN we need to restack the window (and potentially its transients), and if we decide to pay attention to focus, then it just means we also need to restack similarly when the focus of a FULLSCREEN window changes. And indeed, that's what I see. So, yes, the code has changed a fair bit since when I wrote it, and the fact that priority can be "inherited" by transients means that several windows can change priority at the same time, so restacking needs to look for the transients and restack them as well (and be careful not to run the consistency check before they've all been restacked). Stefan
