On Sat, 25 Mar 2017 02:37:23 -0500 "Matthew D. Fuller" <[email protected]> wrote:
> > So, I'll call this a proposed implementation plan. > > Seemingly working implementation in lp:~fullermd/ctwm/otp > <https://code.launchpad.net/~fullermd/ctwm/otp>. > > I've been running it locally, and it hasn't blown up, though I don't > myself normally do anything with OTP. Functionally seems to work as > expected in various combinations of f.*priority, OnTopPriority, > AutoPriority, sending EWMH messages (wmctrl(1) is your friend), and > restarting at various times. > > In dev, I triggered one of the consistency checking assertions once, > but I can't repeat it, so I think it was just an intermediate stage > where I half-converted something. Winding through all the stacking > and OWL arrangement is very twisty, so while I *THINK* everything is > converted right, it's hard to be sure. > > Definitely could use more testing, especially from people who really > make use of OTP. But beware of presumably materially increased > possibility of assertion failures leading to crashes. > > Eyeball reviews sought as well. Unfortunately, there are a fair > number of pretty scattered changes, so it's hard to do it from diff. > I'm going to set it aside for a few days (assuming it doesn't crash on > me, anyway) and then try giving it a fresh review too. > > > Logic goes as: > > - If no OTP for a window is set in config, and it's EWMH-ified as > DESKTOP or DOCK, a default is applied based on those. > > - Whatever OTP values are explicitly set (including via the above) are > tracked as a set level. Doing OTP actions like f.*priority alters > that directly. > > Then the EWMH specific alterations: > > - When EWMH tells us _ABOVE/_BELOW, a flag gets set in OTP data that > applies a +/- offset to what the OTP would otherwise be (based on > the prior). > > - If it is f.fullscreenzoom'ed (which the EWMH STATE_FULLSCREEN > message/prop causes to happen as if we'd done it ourselves), it gets > put all the way on the top when focused, and returned to its natural > level (as calculated above) when not. > > And storing/telling about ABOVE/BELOW: > > - When the effective priority is >0, we set the property to tell the > window it's _ABOVE. <0, _BELOW. > > - We stash up a property on the window that we use to keep track of > when we have the OTP ABOVE/BELOW flags set. On restart we use that > to restore them as necessary, else we use the EWMH ABOVE/BELOW > flags. This way we don't accidentally take our "you're above" > message and double-apply it as "make me above", but still honor > actual client requests. I'd like to cut my teeth on EWMH (and eventually ICCCM), It might take me a little while (1) , but I think I can make a way to check that the code does not create any reversions beyond a doubt (2). Sincerely, David (1). I'm not familiar with it either. Also, my nilfs FS needed rebuilt (nilfs does not have a stable fsck, all minor errors cause a reversion to the last know good checkpoint, anything else requires a reformat), which is why I've not been around. (2) Assuming that you use the doubt 2.0 protocol :)
