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?
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.
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.
I need to think this one through a bit more....
Chers,
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]
