On Tue, Feb 21, 2017 at 02:34:28PM -0500 I heard the voice of
Stefan Monnier, and lo! it spake thus:
>
> > I'm a little unclear about the f.switchpriority/auto-switching
> > cases.
>
> FWIW, the priority switching stuff [...]
Sooo.... hm. One of the reasons I imagine putting it in base is
that it's not quite clear to me that there's a "home" priority you are
sometimes switched from, but rather than either state may be the
long-term base at any given time. And it means we'd need extra state
tracking for 'switched', which reinforced that programmatically we
would have a 'home'.
Maybe that was in error, though. There are some potentially weird
interactions either way we look at things. Let's see how some
scenarios work out...
So either way, we initialize base as
base = get_otp_from_config(wininfo)
if(that told us nothing)
base = get_ewmh_info()
And either way, f.setpriority/f.changepriority adjusts base.
So, let's imagine that via config, the base priority for a window
wound up being, say 4[0]. With no alterations, the effective priority
is now 4 too. When we f.switchpriority it, the effective becomes -4,
and the base is either still 4 or now -4, depending on where we apply
it (my previous mail suggested the latter). Now, what if we
"f.changepriority +2" the window?
If we assume the switch is a flag that alters the effective without
changing the base, the window now gets a base of 6, which means the
effective is now either 6 or -6, depending on whether it's currently
switched. So "changepriority +"'ing now potentially moves it _down_.
That seems a little weird.
If we assume the switch moves the base, though, the window would wind
up with a base of either 6 or -2, depending on whether it was switched
when we changed. So "changepriority +" always moves it up at the
moment. OTOH, if it were switched at the time we did it, and then we
unswitched, we'd wind up at 2, so it would be _lower_ than it was
previously. Suddenly, it's weird again.
So, if we handle switch'ing as a flag that alters the effective
without touching the base, changepriority'ing the window in one
direction will wind up moving it in the opposite direction to what you
expect if it were in switched mode[1] at the time. If it alters the
base, then it moves the home in the opposite direction if you're in
switched state when you do it. They're both kinda odd...
I suppose doing it as a flag to alter the effective is at least
slightly more predictable, because it means that "changepriority +"
always means "move further from the center", no matter what. In
neither case does it always mean "higher on the stack", but in the
base-altering case it can mean further OR closer to the center,
depending on current situation...
Depending on order of application, it can be weird with EWMH
_ABOVE/_BELOW too, but I think by always treating the switching
first (whether doing base, or just doing it first in effective),
we get expected-ish and predictable behavior out of them. So,
that part at least isn't a worry. See, if the EWMH bits hadn't
come up, I wouldn't even have noticed and started worrying about
the above :p
[0] The user-level priority, that is; that means it'd be '12' in the
code. Why are we doing [0..max*2] instead of [-max..max] in the
code? It seems like obvious added complication, and I don't see
what it's buying us...
[1] This ties in with the first paragraph bits, in that we now have a
"home" state for it and a "switched from home", not so much two
more independent states...
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
