When I upgraded to fvwm 2.5.12, snap attraction seemed to break. It will work when I first start/restart fvwm, but then it quickly stops working (acts like it is off).
Also, on a [probably] unrelated note, fvwm randomly exits after being on a long time.
Hmm… Well I just found out that the situation works like this:
I have this:
[code]Mouse 1 T N Generic Raise Move Maximize
Mouse 1 WSFTI M Generic Focus Move Iconify
DestroyFunc Generic
AddToFunc Generic
I $0
M $1
D $2[/code]
Now, Mouse 1 on the titlebar always snap attracts, but Alt + Mouse 1 anywhere on the window only snap attracts the FIRST time that I do it to the window. After that, it no longer works on that window until I restart.
Then, I changed it to Control + Mouse 1:
Mouse 1 WSFTI C Generic Focus Move Iconify
And it works fine! So, somehow the Alt is screwing up the snap attraction.
Also, sometimes when I restart, the titlebar on firefox just disappears!
It does depend how often you find yourself idly holding down the ALT key while dragging window with the mouse. Of course, as you now know this to cause issues, you can stop doing it.
Uh, I use Alt + Mouse for move and resize, just like Gnome and KDE do. It’s a very common practice for many people, and now because of some dumb issue with fvwm I have to switch winkey and meta around in all my fvwm bindings. lame.
I had been noticing this issue (using Alt+mouse to move, no snappy) and finally decided to see if anyone else had had the same issue. I agree with apberzerk that this should be configurable. Maybe a better solution would be to pass an argument to Move to specify whether/how it should snap?