On Sun, Feb 19, 2017 at 10:35:09AM -0500 I heard the voice of
Stefan Monnier, and lo! it spake thus:
>
> That makes a lot of sense. What does the EWMH priority info look like?
> I mean, how compatible is it with ctwm's OTP? We can probably ignore it
> if it's set to 0 (i.e. only obey EWMH if it's set to a non-default.
Well, EwmhGetPriority() already seems to be doing the job of
translating from <whatever EWMH might have to say about stacking> to
<something that fits our OTP worldview>. It just currently gets
treated as the final word, overriding whatever we might have
OnTopPriority'd or AlwaysOnTop'd whenever it gets used[0].
Whether it's best to alter things to "only use EWMH priority stuff if
we didn't set something else ourselves already", or "let EWMH priority
bits relatively adjust what's already set"[1], or some combination,
I'm not sure. Olaf is the one with all the EWMH knowledge; I strive
to maintain my blissful ignorance of the details :)
[0] In a quick look, that's when a window is first mapped and thus we
pick up knowledge of it, when we get EWMH state changes that want
to shift it up/down, and also around stuff related to zoom'ing the
window in/out.
[1] Which I think would be easy on the EWMH adjustments when the
window is first picked up, but trickier on state change bits since
who knows how often/in what order those things happen...
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
