On 29 May 2013 15:16, <gau...@math.cmu.edu> wrote: > 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. > Here is code that was working in Fvwm 2.5.30: > > SetEnv FVWM_WS_DECOR 2 Right, that's OK. > > 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. > DestroyFunc Decorate > AddToFunc Decorate > + I State $[FVWM_WS_DECOR] True > + I WindowStyle !NoTitle !NoTitle? Really? Come on! + I WindowStyle Title > DestroyFunc UnDecorate > AddToFunc UnDecorate > + I State $[FVWM_WS_DECOR] False > + I WindowStyle NoTitle + I WindowStyle Title > Now > > Current DecorateToggle > > would happily toggle decorations of the Current window. Which it does just fine, thank you very much. > 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. > 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
