On Mon, Aug 27, 2001 at 05:39:22PM -0400, Bob Woodside wrote: > Dominik Vogt wrote: > > > > On Sun, Aug 26, 2001 at 11:58:16PM -0400, Bob Woodside wrote: > > > > > > Can you describe for me a scenario that I can try, where the code > > > as I > > > changed it misbehaves? > > > > 1) Move the mouse over a sloppyfocus+mousefocusraises window that > > is not on top. Restart fvwm. Click into the window. The > > window does not raise. > > I can't make this happen (whether it got the focus by being under the > mouse cursor on restart, or didn't get the focus on restart because I'd > moved the cursor away from it). It pops right up when I click on the > client window. Are there any other options I should know about? > > > 2) Create two overlapping sloppyfocus+mousefocusraises windows. > > Focus the upper window. Iconify the lower window via an icon > > manager (FvwmIconMan is fine; the icon manager must use > > NeverFocus). DeIconify the window. It is raised above the > > focused window. Move the pointer into the focused window and > > click. The window does not raise. > > Good. I see the problem here - or at least one of the problems, I don't > know if there are more. The focused window has already spent its grab, > and doesn't get another one because a window was raised over it without > being either clicked on or focused, so f_g_b wasn't called in the > sequence I'd expected. > > Do you know of any more situations that were mishandled?
Any call of f_g_b with is_focused == True is a potential candidate for another bug. There are many calls like this all over the place > I'm beginning to think that f_g_b is really misplaced, and shouldn't be > so tightly bound (in our thinking, at least) to focus issues. I believe > we've been looking at it from two different viewpoints. I was trying to > make the intent of the call clearly either to grab or to ungrab > (mangling the meaning of is_focused in the process), and you were trying > to make the function smart enough to figure out whether a grab or an > ungrab was needed. Neither of us was completely successful. > > > > Could you perhaps describe again what the problem of xfm was? > > xfm, or any program that uses XtTranslations to detect a double-click > (like the test program I sent) has the following problem. If the window > manager has a grab on an ancestor of the app window at the wrong time, > then between the ButtonPress and the ButtonRelease the app sees a > LeaveNotify with mode=grab and an EnterNotify with mode=ungrab (the > opposite of the sequence we see on the parent window), telling the app > window that another window grabbed the pointer and then gave it back. > Actually, Xtlib sees this, which seems to confuse its translation logic, > and it never reports anything but a single click to the app. Then I don't understand why your patch tries to release the grab *later* than before. Doesn't what you say mean that double clicking such windows can never work with MouseFocusRaises? > You may well consider this buggy behavior in Xtlib. I'm inclined to > look on it that way; but I'm also quite sure it's never going to change, > and that we can't have FVWM breaking something this simple and basic. 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]
