On Sun, Feb 19, 2017 at 05:27:29PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> Maybe the most practical approach is "whenever the config file says
> something about stacking, translate it to EWMH stuff and add the
> appropriate property to the window". Then after that, one just looks
> at the EWMH property to decide what to do.
That actually sounds way more invasive, sine we wind up putting a
bunch of stuff that doesn't really have anything to do with EWMH into
some corner of EWMH stuff...
> [...] That is, unfortunately, more complex.
Yeah. Even aside from what it means code-wise, that sounds like it's
just piling up a bunch of user-level complexity in config'ing.
As a given, I don't really know much of anything about either the EWMH
or OTP stuff, apart from what I've come across by accident in looking
at other things, and the little I've seen tracking on this. So, salt
the following with that...
It appears that, to the world outside OTP internals, there are a few
interfaces. There are various *Raise and *Lower and related stuff;
I'm ignoring them here because they don't matter for this analysis.
For our purposes here, there are two; OtpSetPriority() which is
conceptually "=", and OtpChangePriority() which is conceptually "+=".
Change() is actually only used as the backend for f.changepriority.
Set() is what's currently used pretty much everywhere in the code that
non-interactively sets stuff[0]. It [conceptually] happens during the
initial window adoption process. It happens right after that,
overriding with the EWMH bits; that being the base of the current
issue.
It happens during the zoom process, in the EWMH case, using the EWMH
FULLSCREEN priority. Which isn't the max OTP priority, so it sound
seem that f.zoom'ing an app might not put it on top of everything
else. It seems like it's also [re]setting that on focus in when it's
zoomed too, which is... odd. Presumably it's doing that because it
re-sets it down to EwmhGetPriority() on focus out, which seems even
wronger. And getting changes in the EWMH_STATE_{ABOVE,BELOW} re-alter
it as well (ties in with infra).
The core of the lookup here is EwmhGetPriority(). There are the
special Desktop (below everything) and Dock (a bit above the default)
window types, but presumably pretty much everything we care about
winds up being neither, which means it winds up on plane 0, unless
it's on +/- 2 by virtue of having the ABOVE/BELOW states set, which
the spec says mean "above or below most windows". It seems a
reasonable tradeoff to me that the desktop/dock cases can reasonably
just override as they are; trying to be smarter sounds very
complicated and fragile and hard to understand anyway. And those seem
like they'd probably usually be windows you wouldn't be much messing
with anyway.
But, normal seems like it should mean "where the window would
otherwise be", not necessarily 0. So, one interesting route would be
to base off OtpGetPriority() instead of EWMH_PRI_NORMAL in
EwmhGetPriority(). Then the above/below would adjust relative to
that. Now, that would mean that repeated applications of those state
shifts would cause it to bubble all the way one direction or the
other; they become increments rather than states. Maybe the handler
of state changes could be made a bit smarter about only applying them
when they actually change, and that would paper over that problem? It
seems like it might also interact poorly with the use of EGP() in the
focus-out handler, described supra. (see also [1])
So, it seems from a fairly quick investigation like the handling
during the create/map process may need to be handled a bit differently
than the things done in the zoom process, and how the ABOVE/BELOW
hints get used considered in light of those differences.
But currently, the whole EwmhGetPriority() schema is incompatible with
the idea that you might be setting or changing the window's priority
in any other way. So far here we're talking mostly about
config-mandated placement. But e.g. even if you use f.changepriority
to move a window around, next time an EWMH ABOVE/BELOW state change
happens, or as soon as you FocusOut of a f.fullscreenzoom'd window, it
gets smacked to -2/0/+2 no matter where you'd put it before.
[0] I'm largely ignoring the interactive bits here, since they don't
matter for this discussion. f.setpriority, f.raise/lower, blah
blah blah...
[1] I gloss here right over the oddity where we set the NET_WM_STATE
property, where there's a "OtpGetPriority() - EwmhGetPriority()"
dance to guess which direction to alter things. That wouldn't fit
with the above change, and seems... weird anyway.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
