FVWM: Something fishy with State in 2.6.5

Thomas Adam

2013-07-25 19:51:51 UTC

Post by g***@math.cmu.edu
Dear All,
I'm having trouble testing "State" in Fvwm 2.6.5.

Then try the CVS version because it works for me---your functions have
what I'd consider a bug in them mind.

Post by g***@math.cmu.edu
SetEnv FVWM_WS_DECOR 2

Right, that's OK.

Post by g***@math.cmu.edu
DestroyFunc DecorateToggle
AddToFunc DecorateToggle
+ I ThisWindow (State $[FVWM_WS_DECOR]) UnDecorate
+ I TestRc (NoMatch) ThisWindow Decorate

Now we get in to interesting waters. Not that this is your fault, of
course, it's just that no one understands context of windows or
functions. None of what I'm about to tell you has any bearing on your
problem of these not working---I can't tell why they don't work, all I
can tell you is that they work as you intended them to. If you _can_
reproduce this with the CVS version then I'll perhaps care a little
more.

Anyway, look at this:

Current DecorateToggle

Does this mean DecorateToggle runs on the focused window? Yes it
does. Does it mean that commands inside it will run against the
window matched by the conditional command 'Current'? Probably.

+ I ThisWindow (State ....) UnDecorate
+ I TestRc (NoMatch) ThisWindow Decorate

So "ThisWindow" means just that---the window. The context of
"ThisWindow" varies depending on what you're doing, and how you've
invoked something. But earlier you said to FVWM that the
currently-focused window is to have some function "DecorateToggle"
applied. This runs against that window, and hence the "ThisWindow
Decorate" is a little strange here. You don't use: "ThisWindow
UnDecorate"---why? The use of "ThisWindow" is superfluous; it won't
harm anything, but it's meaningless because we set the window context
already; via "Current". If no such window existed, bugger all would
happen. Hence:

DestroyFunc DecorateToggle
AddToFunc DecorateToggle
+ I ThisWindow (State $[FVWM_WS_DECOR]) UnDecorate
+ I TestRc (NoMatch) Decorate

There. Much less to read on the eyes.

Post by g***@math.cmu.edu
DestroyFunc Decorate
AddToFunc Decorate
+ I State $[FVWM_WS_DECOR] True
+ I WindowStyle !NoTitle

!NoTitle? Really? Come on!

+ I WindowStyle Title

Post by g***@math.cmu.edu
DestroyFunc UnDecorate
AddToFunc UnDecorate
+ I State $[FVWM_WS_DECOR] False
+ I WindowStyle NoTitle

+ I WindowStyle Title

Post by g***@math.cmu.edu
Now
Current DecorateToggle
would happily toggle decorations of the Current window.

Which it does just fine, thank you very much.

Post by g***@math.cmu.edu
This worked perfectly in 2.5.30 and prior versions. However, when I
upgraded my Debian box recently, it stopped working in 2.6.5. (I also
interject many "Current" or "ThisWindow" commands into the above with no
success.)

And this entire paragraph is why you have a long-winded explanation
above. Don't do that, please. They mean different things, and
conflating them is not cool; and only shows people are all too happy
to fumble around in the dark for any kind of result, rather than
appreciating _what_ it is they're doing.

Post by g***@math.cmu.edu
Any ideas? I Googled "Fvwm State 2.6.5" etc. before posting, but didn't
have much luck.

Well, when you follow the logic through, you have your conditions
backwards, no? On first calling "Pick DecorateToggle" [1] if the
window doesn't have the state set then it will call "Decorate" until
you call it a second time, in which case it undecorates. Subsequent
calls then toggle.

I would use something like the following instead, which work, by the
way, in CVS. I don't care to test anything else:

SetEnv FVWM_WS_DECOR 2

DestroyFunc DecorateToggle
AddToFunc DecorateToggle
+ I ThisWindow (!State $[FVWM_WS_DECOR]) UnDecorate
+ I TestRc (NoMatch) Decorate
+ I State $[FVWM_WS_DECOR]

DestroyFunc Decorate
AddToFunc Decorate
+ I WindowStyle Title

DestroyFunc UnDecorate
AddToFunc UnDecorate
+ I WindowStyle !Title

Note this doesn't require a separate State line in both Decorate or
Undecorate; you guarantee to always perform one of them, so simply
toggle the flag at the end of calling one of them.

-- Thomas Adam

[1] I bet that one's got you thinking, eh? ;P