Re: xfm and moxfm: Once more unto the breach...
On Fri, Aug 17, 2001 at 03:18:18PM -0400, Bob Woodside wrote: Bob Woodside wrote: Well, this one has led me a merry chase...and I'm still chasing. The problem seems to be mostly confined to focus.c: focus_grab_buttons, which doesn't quite work as intended. I've hacked it up to the point where it does what I think was intended. It seems to work pretty well, except that it breaks MouseFocusClickRaises. There is clearly some additional synchronization needed that I haven't figured out yet. OK, I think I've finally got it right. Dominik, if you have a chance to look over (or try out) the attached patch against last night's CVS, and see if it breaks anything for you, I'd appreciate it. You did so much work rewriting and resynchronizing all that grab stuff, I'd hate to break something you had fixed. I don't thionk I did, but since I wasn't able to follow the development very closely at the time, I don't know for sure what problems you were addressing, or what apps or modes to try out. Anyway, if I don't hear any screams, squawks, or curses, I'll commit this in a day or two (I'd also like to let it run on a couple of machines here for a day or so, just to see.) Actually, I don't understand my code anymore. I think the idea was to call focus_grab_buttons() each time the pointer enters or leaves a window or a window is (un)focused. The function would then make the proper grabs. I don't quite understand the implications of the code you added to MoveFocus(). Won't not calling focus_grab_buttons() screw something up elsewhere? I don't know. However, with your patch, fvwm passes through the for (...) loop much more often then necessary. Could you try to write some condition like the former if (grab_buttons != tmp_win-grabbed_buttons) to prevent fvwm from entering the loop unnecessarily? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
Re: xfm and moxfm: Once more unto the breach...
Dominik Vogt wrote: However, with your patch, fvwm passes through the for (...) loop much more often then necessary. Could you try to write some condition like the former if (grab_buttons != tmp_win-grabbed_buttons) to prevent fvwm from entering the loop unnecessarily? Yeah, I was thinking of trying to add something like that; I just wanted to get the darn thing working first. The problem with the original test is that it is only valid when you enter for a grab - for an ungrab, the test needs an inverted mask; and formerly we always set tmp_win-grabbed_buttons = grab_buttons on exit, so that after the first pass through for a given window, this test would cause us to exit prematurely without actually doing anything. I'll try to put a test like this in before committing the changes. I don't quite understand the implications of the code you added to MoveFocus(). Won't not calling focus_grab_buttons() screw something up elsewhere? These 2 calls in MoveFocus() to *ungrab* the buttons happen prematurely for the case of MouseFocusClickRaises windows (we're still waiting for a possible click). They never caused a problem before because focus_grab_buttons() didn't actually do the ungrab (because of the test mentioned above). That's why MouseFocusClickRaises broke when I made focus_grab_buttons() actually do the ungrab. I've been running with these changes on 2 machines for a couple of days now, and haven't noticed anything untoward happening. I've tried to exercise all the combinations of focus policy options (we support so many!), so it's probably about time to see if other people find problems with them. Cheers, Bob -- 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]
Re: xfm and moxfm: Once more unto the breach...
On Sun, Aug 19, 2001 at 01:36:24PM -0400, Bob Woodside wrote: Dominik Vogt wrote: However, with your patch, fvwm passes through the for (...) loop much more often then necessary. Could you try to write some condition like the former if (grab_buttons != tmp_win-grabbed_buttons) to prevent fvwm from entering the loop unnecessarily? Yeah, I was thinking of trying to add something like that; I just wanted to get the darn thing working first. The problem with the original test is that it is only valid when you enter for a grab - for an ungrab, the test needs an inverted mask; and formerly we always set tmp_win-grabbed_buttons = grab_buttons on exit, so that after the first pass through for a given window, this test would cause us to exit prematurely without actually doing anything. I noticed some problems with MouseFocusClickRaises in the past months (i.e. a click didn't raise the window sometimes) but could never find a way to make it happen on command. Maybe your patch fixes this after all. I don't quite understand the implications of the code you added to MoveFocus(). Won't not calling focus_grab_buttons() screw something up elsewhere? These 2 calls in MoveFocus() to *ungrab* the buttons happen prematurely for the case of MouseFocusClickRaises windows (we're still waiting for a possible click). They never caused a problem before because focus_grab_buttons() didn't actually do the ungrab (because of the test mentioned above). That's why MouseFocusClickRaises broke when I made focus_grab_buttons() actually do the ungrab. I've been running with these changes on 2 machines for a couple of days now, and haven't noticed anything untoward happening. I've tried to exercise all the combinations of focus policy options (we support so many!), so it's probably about time to see if other people find problems with them. I think we can risk this. Your patch changes something under very peculiar circumstances, so even if it broke something, probably only a few people would ever notice. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
Re: xfm and moxfm: Once more unto the breach...
Bob Woodside wrote: Well, this one has led me a merry chase...and I'm still chasing. The problem seems to be mostly confined to focus.c: focus_grab_buttons, which doesn't quite work as intended. I've hacked it up to the point where it does what I think was intended. It seems to work pretty well, except that it breaks MouseFocusClickRaises. There is clearly some additional synchronization needed that I haven't figured out yet. OK, I think I've finally got it right. Dominik, if you have a chance to look over (or try out) the attached patch against last night's CVS, and see if it breaks anything for you, I'd appreciate it. You did so much work rewriting and resynchronizing all that grab stuff, I'd hate to break something you had fixed. I don't thionk I did, but since I wasn't able to follow the development very closely at the time, I don't know for sure what problems you were addressing, or what apps or modes to try out. Anyway, if I don't hear any screams, squawks, or curses, I'll commit this in a day or two (I'd also like to let it run on a couple of machines here for a day or so, just to see.) Cheers, Bob grabfix.diff.gz Description: Binary data
Re: xfm and moxfm: Once more unto the breach...
Well, this one has led me a merry chase...and I'm still chasing. To recap the problem: it boils down to the need to suppress Xlib's automatic grab when a mouse button is pressed, and the unwanted LeaveNotify/EnterNotify events generated by that grab; and it's the Leave/Enter events that confuse Xtlib's double-click translation logic. This automatic grab used to be overridden by our button grabs on the parent window, but that's not happening at present. The problem seems to be mostly confined to focus.c: focus_grab_buttons, which doesn't quite work as intended. I've hacked it up to the point where it does what I think was intended. It seems to work pretty well, except that it breaks MouseFocusClickRaises. There is clearly some additional synchronization needed that I haven't figured out yet. Dominik, if I can't work out the remaining piece in a few days, I'd like to send you a patch to see if you have any ideas. (I'd rather not commit my changes as they stand now, knowing that they will break something.) Cheers, Bob -- 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]
Re: xfm and moxfm: Once more unto the breach...
Bob Woodside wrote: Dominik Vogt wrote: Anyway, if you send me your sample program I'll have a look at the problem. Erm...it was attached to the last email. However, ignore it. I'll send you a revised version, if you like, that reveals more information. Here's what it shows. The Leave/Enter events are semi-spurious. They occur (in that order) between every Btn1Down and Btn1Up, and they have mode = NotifyGrab and mode = NotifyUngrab, respectively. This happens when the pointer gets grabbed away from the window it's currently in. It looks like we're grabbing way too often - or possibly even doing the whole focus thing too often - on every single click. This should happen only on the first click needed to transfer focus to the window, not on subsequent clicks when the window already has the focus. It confuses the Xt lib routines that handle double click detection. On further investigation, I can't see any extra grabs occurring. But upon looking at the changes in events.c (HandleEnterNotify and HandleLeaveNotify), I see you've been wrestling with this general problem already, a few months ago. It looks as though we may have some more fine-tuning to do in that area. I'm attaching the revised version of the test program - it's really little more than a textbook example that *should* work as is. Cheers, Bob dblclktst2.tar.gz Description: GNU Zip compressed data
Re: xfm and moxfm: Once more unto the breach...
Dominik Vogt wrote: Well, that does not sound strange at all. I guess the widget window has not selected Enter/Leave events, but it has selected ButtonPress events. Thus, clicking into the widget window should generate Enter/LeaveNotify events on the widget window. If the application does not want these events it should not select them, right? Anyway, if you send me your sample program I'll have a look at the problem. Erm...it was attached to the last email. However, ignore it. I'll send you a revised version, if you like, that reveals more information. Here's what it shows. The Leave/Enter events are semi-spurious. They occur (in that order) between every Btn1Down and Btn1Up, and they have mode = NotifyGrab and mode = NotifyUngrab, respectively. This happens when the pointer gets grabbed away from the window it's currently in. It looks like we're grabbing way too often - or possibly even doing the whole focus thing too often - on every single click. This should happen only on the first click needed to transfer focus to the window, not on subsequent clicks when the window already has the focus. It confuses the Xt lib routines that handle double click detection. Now that I understand what's happening from the app's perspective, maybe I can figure out where we went astray...if you don't beat me to it! Cheers, Bob -- 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]
Re: xfm and moxfm: Once more unto the breach...
On Wed, Aug 01, 2001 at 11:48:04PM -0400, Bob Woodside wrote: Bob Woodside wrote: Dominik Vogt wrote: ? On the other hand it seems SuSE 7.2 ships with a much improved xfm version (1.4.2.patchl04). Perhaps the problem has been solved there. Curious...I grabbed the 1.4.2p4 tarball, and it does indeed work. Their Changelog mentions a fix (in 1.4.2p3) that addresses this: double clicks in the file window finally work in ol[v]wm/kwm even if the focus policy is click to focus (app window still needs to be fixed). I'll have to see what they did, and discuss it with the current maintainer. I discussed this with Till Straumann, who made this fix for xfm. He said that they'd found that, under kwm and ol(v)wm, extraneous EnterNotify/LeaveNotify events were getting sent to the widgets on which double clicks failed, which seemed to confuse the XtTranslations stuff used to catch a double click. His workaround was to insert an event handler that would simply eat these events. This is exactly what is happening with FVWM now (in ClickToFocus mode), and it looks like a bug to me. I know, what the window manager does isn't supposed to interfere with the top level's interaction with its children, but that appears to be what we're doing, somehow. To test this, I created a minimal program with a label widget and an XtTranslations string to catch a double click. It fails. I added an event handler to eat the extra events, just like the one in the latest xfm, and it works. The source is attached. Compile it as it is and run it with MouseFocus, and the label text changes when you double click on it; with ClickToFocus, it fails. Comment out the line #undef EATENTERLEAVEEVENTS, and the event handler eats the extra events and the program works under either focus policy. I don't have any idea yet where the problem lies or when it may have been introduced (sometime within the past year covers a lot of territory). The only thing I'm pretty sure of now is that it's *not* in your changes to the grab code (well, that's the area where one of us - probably me - introduced this symptom before). Any ideas? Well, that does not sound strange at all. I guess the widget window has not selected Enter/Leave events, but it has selected ButtonPress events. Thus, clicking into the widget window should generate Enter/LeaveNotify events on the widget window. If the application does not want these events it should not select them, right? Anyway, if you send me your sample program I'll have a look at the problem. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
Re: xfm and moxfm: Once more unto the breach...
Bob Woodside wrote: Dominik Vogt wrote: ? On the other hand it seems SuSE 7.2 ships with a much improved xfm version (1.4.2.patchl04). Perhaps the problem has been solved there. Curious...I grabbed the 1.4.2p4 tarball, and it does indeed work. Their Changelog mentions a fix (in 1.4.2p3) that addresses this: double clicks in the file window finally work in ol[v]wm/kwm even if the focus policy is click to focus (app window still needs to be fixed). I'll have to see what they did, and discuss it with the current maintainer. I discussed this with Till Straumann, who made this fix for xfm. He said that they'd found that, under kwm and ol(v)wm, extraneous EnterNotify/LeaveNotify events were getting sent to the widgets on which double clicks failed, which seemed to confuse the XtTranslations stuff used to catch a double click. His workaround was to insert an event handler that would simply eat these events. This is exactly what is happening with FVWM now (in ClickToFocus mode), and it looks like a bug to me. I know, what the window manager does isn't supposed to interfere with the top level's interaction with its children, but that appears to be what we're doing, somehow. To test this, I created a minimal program with a label widget and an XtTranslations string to catch a double click. It fails. I added an event handler to eat the extra events, just like the one in the latest xfm, and it works. The source is attached. Compile it as it is and run it with MouseFocus, and the label text changes when you double click on it; with ClickToFocus, it fails. Comment out the line #undef EATENTERLEAVEEVENTS, and the event handler eats the extra events and the program works under either focus policy. I don't have any idea yet where the problem lies or when it may have been introduced (sometime within the past year covers a lot of territory). The only thing I'm pretty sure of now is that it's *not* in your changes to the grab code (well, that's the area where one of us - probably me - introduced this symptom before). Any ideas? Cheers, Bob dblclktst.tar.gz Description: GNU Zip compressed data
Re: xfm and moxfm: Once more unto the breach...
Dominik Vogt wrote: I see no problem at all. Are you sure you are using Style * ClickToFocusPassesClick Yup. ? On the other hand it seems SuSE 7.2 ships with a much improved xfm version (1.4.2.patchl04). Perhaps the problem has been solved there. Curious...I grabbed the 1.4.2p4 tarball, and it does indeed work. Their Changelog mentions a fix (in 1.4.2p3) that addresses this: double clicks in the file window finally work in ol[v]wm/kwm even if the focus policy is click to focus (app window still needs to be fixed). I'll have to see what they did, and discuss it with the current maintainer. Cheers, Bob -- 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]
Re: xfm and moxfm: Once more unto the breach...
On Fri, Jul 27, 2001 at 01:54:44PM -0400, Bob Woodside wrote: Hi, all -- After way too long an absence, I finally got around to installing 2.4.0, and discovered that the old no double-clicks getting passed to xfm and moxfm problem that I fixed back in December of 1999 has resurfaced, at least partly. This time it only appears to affect ClickToFocus mode. I see no problem at all. Are you sure you are using Style * ClickToFocusPassesClick ? On the other hand it seems SuSE 7.2 ships with a much improved xfm version (1.4.2.patchl04). Perhaps the problem has been solved there. Dominik, it looks like it was probably introduced with some of the grab changes you made in the Sept-Nov 2000 timeframe. (Obviously, I haven't done a CVS update in a long time.) It'll take me a while to get back up to speed on what's going on in that area. I see my old footprints in the code, but the surrounding sand is all different. Now to see if my CVS and build setup still works Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
xfm and moxfm: Once more unto the breach...
Hi, all -- After way too long an absence, I finally got around to installing 2.4.0, and discovered that the old no double-clicks getting passed to xfm and moxfm problem that I fixed back in December of 1999 has resurfaced, at least partly. This time it only appears to affect ClickToFocus mode. Dominik, it looks like it was probably introduced with some of the grab changes you made in the Sept-Nov 2000 timeframe. (Obviously, I haven't done a CVS update in a long time.) It'll take me a while to get back up to speed on what's going on in that area. I see my old footprints in the code, but the surrounding sand is all different. Now to see if my CVS and build setup still works Cheers, Bob -- 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]
