On Mon, Jul 28, 2003 at 04:11:15PM +0200, Dominik Vogt wrote: > On Mon, Jul 28, 2003 at 03:52:15PM +0200, Olivier Chapuis wrote: > > On Wed, Jul 23, 2003 at 02:36:59PM +0200, Dominik Vogt wrote: > > > On Wed, Jul 23, 2003 at 08:07:32AM -0400, Ben Winslow wrote: > > > > Since I could reproduce this, I decided to track it down... > > > > > > > > fvwm is indeed trying to grab the pointer and failing [XBell() at > > > > functions.c:992 in execute_complex_function], however, it's not because > > > > of anything Jules has done... > > > > > > > > In ConfigFvwmDefaults, an EWMHActivateWindowFunc function is > > > > defined--whenever gkrellm is clicked on to be moved (I think GTK2 is > > > > what's actually causing this to happen), EWMHActivateWindowFunc is > > > > called, causing this problem. > > > > > > Which gkrellm version? It doesn't happen with 1.2.10. Anyway, > > > this is a gkrellm bug: > > > > > > An application can not expect that the window manager processes > > > any requests (_NEW_WM_ACTIVE_WINDOW client message in this case) > > > while the server/pointer/keyboard is grabbed. This should be > > > fixed in gkrellm. > > > > Maybe. But it is not always needed to grab the pointer when we execute > > a complex function. So, I suggest that when fvwm fail to grab the > > pointer for executing a complex function we do not abort the function > > execution. This fix Jules problem (that I can reproduce, and it > > happens the same thing with the Mozilla resize grip). What do you > > think? > > I think it's a bad idea. It is practically impossble to guess > whether a function needs to grab the pointer before executing or > not, and it depends on what other application do too. For > example, if an application warps the pointer while a function is > executed, all sorts of strange things can happen. >
In fact I can reproduce the gkrellm problem only on certain condition: I've a FvwmEvent running which executes a complex function on each module events. fvwm bell and abort a complex function which is run with a raise_window (gkrellm) or a configure_window (Mozilla resizing with grip). Also I've an FvwmEvent which auto shade a FvwmButtons with a delay via leave_window (with the schedule command and a "shade" complex function). When, I leave the FvwmButtons and popup a menu of an application before auto shade the "auto shade" complex function xbell and abort. So I really think that by default we should not abort complex functions when we cannot grab the cursor. Maybe a Grab prefix or a Grab function (with automatic ungrab) should be introduced, but I _think_ that the case where we need to grab is exceptional. Do you have a real life example (say in your fvwm config)? > > Note that the "problem" does not arise to me with 2.5.7 and I think > > that it appears _for me_ during your recent work on ConfigureRequest > > Event. > > I don't think so. That has nothing to do with the problem. > Yes, Sorry, no FvwmEvent running when I do the test with 2.5.7. Regards, Olivier -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
