possible bug with AnimatedMove

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:

  1. Is this really a bug?
  2. What does FVWM actually do when the AnimatedMove is occuring?
  3. Any way around this?

I can post some test code if necessary.

Well I suppose this is a known issue. I found this in my config, which is based off taviso’s.


Telling a window that is already moving to AnimatedMove is not a good idea!

This function makes sure the user doesnt accidentally catch a window twice, by

setting one of the windows states while it is being moved.

Every window has around 30 user definable states which you can test in

functions, you can use them for anything you like.

DestroyFunc LockingSlide
AddToFunc LockingSlide

  • I Test (!State 2) Break
  • I State 2 False
  • I AnimatedMove $0 $1
  • I State 2 True

Not sure how to use this function at all however…

Also, I don’t understand why executing the AnimatedMove commands back to back work fine (like running them one after another in a loop), but when combined with a mouse click event things go wacky.

Well what do ya know… locking slide worked great. It is used in teh exact same manner as AnimatedMove, so it is basically a wrapper.

Only bug is that I get this in my .xsession-errors:

Unrecognised condition "State" in Test command.


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:

SetAnimation 220

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:

PlaceAgain Icon Anim


– Thomas Adam

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.

It doesn’t help, but it would have been a possible explanation, is all.

– Thomas Adam