> 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.



-- 
Matthew Fuller     (MF4839)   |  [email protected]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.

Reply via email to