Re: OTP/EWMH (was Re: AlwaysOnTop xclock)

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 :)