I’m having an issue while using AnimatedMove. I have a script that moves a window from one side of the window to the other (and the reverse). This is hooked into an icon on my desktop.
I have noticed that if I click the icon again while the window is still moving, FVWM won’t accept any more mouse signals (clicks, mouseovers). Things return to normal if I do a ‘FvwmCommand Restart’ from the commandline.
I am 99.9% sure this has something to do with the AnimatedMove, as I have tested it in a variety of ways, including triggering the signal from a GTK app. Everytime I click too soon FVWM locks. I have tried to build lockfiles, and timers around the command, but it is of no use, because the error occurs when the new signal is emitted.
So, a few questions:
Is this really a bug?
What does FVWM actually do when the AnimatedMove is occuring?
It does a number of things, including moving the window in small steps, redrawing it, and grabbing the keyboard.
Yes – the pointer should really be grabbed if the “Warp” option isn’t specified. The reason it worked for you via a function is because when a complex function is executed, the pointer is already grabbed. I was able to reproduce your problem by setting:
And then AnimateMove a window to 0 0. Note that clicking the mouse or pressing a key during this time aborts the animation of the window and
doesn’t block. Out of interest, with regards to the icon you speak of, do
you have something like:
Ok, that makes sense. I edited the LockingSlide function to only contain the AnimatedMove command and it worked just the same (due to the pointer warping that you mentioned).
No I’m not using this. I actually use the icon to move a weathermap on/off the screen when I click my weather icon (it’s pretty cool 8) ). I control it by checking where the window currently is (using xwininfo) and then move it accordingly. I read the man page for PlaceAgain, but I wasn’t sure how it would help.