On 20 Jun 2004 14:24:45 +0100, Tavis Ormandy wrote: > > Hello, telling windows to AnimatedMove while already in an AnimatedMove > operation seems to leave the server grabbed, i work around it with a > simple wrapper function that uses States to make sure it's safe: > > DestroyFunc LockingSlide > AddToFunc LockingSlide > + I Test (!State 2) Break > + I State 2 False > + I AnimatedMove $0 $1 > + I State 2 True > > You can test it with this: > > DestroyModuleConfig MoveTest: * > *MoveTest: Geometry 100x100 > *MoveTest: (Action Current AnimatedMove w-10p keep, Title "Click Me") > Module FvwmButtons MoveTest > > if you click it really fast a few times, you will see what I mean :) > > Is this workaround nescessary, or have I found a bug?
Probably a bug, but something is missing here for a minimal reproducable config. Probably you use FvwmEvent too. > secondly, is there any reason why fvwm-menu-directory has the menu name > 'FuncFvwmMenuDirectory' hardcoded? > > I have two different functions that handle browsing directories, one is > a general browser and the other browses images, in the second one I have > to sed out the menu Name so that moving to a subdirectory doesnt confuse > it...would a patch be accepted that stopped it from ignoring the --name > option witout --reuse? This is not a good fix. --name is a menu name in all fvwm-menu-* scripts, using it as a function name would be confusing. I will add some new option like --missing-subdir-function (or better yet --func-name) later. Regards, Mikhael. -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
