On Sun, Feb 19, 2017 at 07:43:25PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> It has been a while since I looked into it so from time to time it
> looks weird to me too :-)
OK, so after a bunch of thinking back and forth, it seems like we
probably need some hybrid handling. Following is what I've come up
with; comments especially solicited from those actually understanding
how OTP should work...
I think we need to track a 'base' OTP, and a 'effective'. (there's
also save_otpri, which is different). So, we set initial conditions:
For the EWMH window types, these are apparently all initial
conditions; we get told 'em when the window is created, and they don't
get to change afterward. That simplifies things nicely. So, our
initial state can be set like "if we have an OTP set for it in the
config file, use that, else we can use the _DESKTOP/_DOCK/_NORMAL EWMH
bits we currently have as defaults".
That gives us a starting base OTP for each window. Then we allow the
f.setpriority and f.changepriority functions to adjust that base OTP.
Then, we have potential adjustments to that base, to the effective OTP.
I think we definitely want the EWMH FULLSCREEN[1] stuff to fall into this
category. Probably the ABOVE/BELOW as well[0].
I'm a little unclear about the f.switchpriority/auto-switching cases.
My best guess currently is that they should probably be altering the
base, because (a) practical implementation simplicity, and (b)
conceptual long-term nature of the change (i.e., it's more a change
like f.changepriority, than a toggle like f.fullscreenzoom).
So this leaves us with the 3 tracked OTP bits.
- effective_otp: which plane the window is currently in.
- base_otp: what we use as a basis for various times we calculate an
effective_otp to set.
- save_otpri: as currently used; a stashed value for various zoom
functions to return it to where it should be when we un-zoom.
Calculating effective_otp would then involve something like
if(fullscreenzoom'd)
eff = the ceiling;
else
eff = base_otp;
eff = eff +/- 2 based on EWMH ABOVE/BELOW
I think that actually obviates save_otpri in the fullscreenzoom case,
since when un-zooming you could just recalc the effective. I'm not
sure what it would mean for the other zoom types, where we just
OtpRaise() things; from looking at the code, it _seems_ like OtpRaise
either does a priority switch if the window is switchable, or just
raises it to the top of its current plane if not; in that case we'd
still need save_otpri to know where to restore it to, unless we
embedded further knowledge of whether it was switched?
There's an edge case here for what should happen if the base or
alterations get changed while we're zoomed; we may get EWMH
ABOVE/BELOW changes, or the user might f.changepriority, etc.
(this is all pushing my knowledge of OTP stuff pretty much to and past
its limits, both from a how-the-code-works perspective, and from the
what-these-settings-are-supposed-to-mean-to-the-user side as well...)
[0] I could argue various ways about how ABOVE/BELOW should act/not on
explicitly set-in-config OTP vs. f.{set,change}priority'd OTP vs.
completely default. My gut says that from both a dev-side code
perspective, and a user-side predictability perspective, it's best
if they either _always_ alter the effective OTP, or _never_ do.
[1] I think there are probably some oddities in the current
implementation of this that need some smoothing, but probably
nothing major.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
