Actually I opened FvwmConsole only after I experienced the problems and noticed they didn't happen when Fvwm wasn't running. Which means the problems definitely are present with FvwmConsole closed.
Hope this helps. On Tue, Aug 12, 2014, at 17:14, Thomas Adam wrote: > On Mon, Aug 11, 2014 at 04:21:03PM +0200, Tobias Landes wrote: > > I actually tried that even before contacting you. The effect is just the > > same (except FvwmConsole now complains about not finding the function > > instead of displaying the error). But Fvwm hangs nevertheless. > > > > Sure hope this will help to clear things up. I'll be happy to assist in > > any way I can. > > So what's happening here is that the grab isn't happening before the > immediate action can be performed. I think this would benefit from a helper > function in libs/XError.c to print out the human-readable return value from > XGrabPointer() and then we can see what's happening. > > It might be trying to grab itself over and over again, although I doubt it. > Note that if you close FvwmConsole, I suspect your problem might go away > somewhat. > > FvwmConsole's socket/pipe handling is completely broken, and in moving a > window, I'm noticing that it's being sent a tonne of broadcast packets for > every ConfigureNotify request occuring. This floods the pipes between FVWM > and FvwmConsole until it can be flused. > > BAsically, FvwmConsole needs scrapping and replaced with something more > robust for this problem to ever go away. However, if you do something like: > > ModuleTimeout 1 > > Does this help any? > > Basically, although the grabs are failing for you in the function(s) you've > specified, I'm suggesting the problem is elsewhere; with FvwmConsole being a > typical candidate for this. > > -- Thomas Adam >
