Subject: new MouseFocusRaises problem

From: Dominik Vogt <[email-masked]>
Date: Sat, 25 Aug 2001 18:07:34 +0200

Bob, I had to restore some of the old logic in focus_grab_buttons().
What I do not understand is your motivation to reverse buttons
grabbing for the focused window.  I think you assumed that calling
the function with is_focused == 1 means to ungrab the window -
which is wrong.  It still grabs buttons if the (focused) window has
MouseFocusClickRaises and is not on top of all other overlapping
windows.  I have removed/rewritten/commented the parts dealing
with focus handling in focus_grab_buttons().

Then there is the stuff in MoveFocus which suppresses ungrabbing
buttons of the focused window if it is already on top.  I guess
this causes the problem with xfm, but actually your fix means that
these buttons are not ungrabbed at all, regardless if the window
is on top or not, i.e. the grabs are permanent as long as the
window is focused, right?  But this could be done much easier in
f_g_b():

  if (<mousey_focus> && is_focused)
    grab_all
  else if ...

This has to be cleaned up before 2.4.1.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Sun, 26 Aug 2001 23:58:16 -0400

Dominik Vogt wrote:
> which is wrong.

	This is really curious. It certainly looked like the intent of
is_focused == 1 was to ungrab, anc vice-versa. [sigh.] That's the
disadvantage of having been inactive for so long. In the code as it was,
I could never see the ungrab in f_g_b happening, and I often couldn't
see the grab happening where it seemed it should (based on several
printfs I finally inserted in desperation).

> It still grabs buttons if the (focused) window has

	Have you committed your changes yet? I didn't see a mention of them
come through the mailing list from CVS.

	Can you describe for me a scenario that I can try, where the code as I
changed it misbehaves? Then I can use that as a sanity check. I haven't
seen any untoward behavior on my systems, but I'm obviously not
exercising either the apps or the combinations of style options that are
causing problems.

> this causes the problem with xfm, 

	Not really, this was because my changes to f_g_b caused an ungrab to
happen prematurely for a MouseFocusClickRaises window, so we never
caught the click to raise it.

> but actually your fix means that
> window is focused, right?  

	Until someone clicks on it. But I think I overlooked the case of an
AutoRaise happening (which I don't use - I always explicitly click to
raise).

> But this could be done much easier in
> f_g_b():
> 

	Hmmm. I'll have to think about this after I get a look at your changes.

> This has to be cleaned up before 2.4.1.

	Absolutely.

Cheers,
Bob

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 27 Aug 2001 10:01:00 +0200

> come through the mailing list from CVS.

Yes.

> exercising either the apps or the combinations of style options that are

 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.

 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.

> 	Hmmm. I'll have to think about this after I get a look at your changes.

Could you perhaps describe again what the problem of xfm was?

Bye

Dominik ^_^  ^_^

---

From: Bob Woodside <[email-masked]>
Date: Mon, 27 Aug 2001 17:39:22 -0400

Dominik Vogt wrote:
> > changed it misbehaves?

	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?

>     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

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 30 Aug 2001 01:27:06 +0200

> 	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

> 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?

Bye

Dominik ^_^  ^_^

---

From: Bob Woodside <[email-masked]>
Date: Thu, 30 Aug 2001 01:06:58 -0400

> for another bug.  There are many calls like this all over the place

	Yes. It's scary. I thought I had covered all the cases, but I obviously
hadn't.

> > so tightly bound (in our thinking, at least) to focus issues.
> >
> >

	No. With my original patch to f_g_b, the double click worked fine with
MouseFocusClickRaises (and with all the other modes); it was the raising
on the click that no longer worked. In the 2 spots I then changed in
MoveFocus the grab was being released prematurely for a
MouseFocusClickRaises window (on a focus change, but before a click
happened): therefore we didn't catch the click and didn't raise the
window. This didn't happen before my patch because those calls to f_g_b
didn't ungrab - in fact they didn't do anything. (Actually, sticking
some printfs in f_g_b, I could never see an ungrab happening, which I
think was the original source of the double click problem.)

	With the changes to MoveFocus, both double clicking and raising worked
fine. Unfortunately, in the icon manager case you mentioned, where
another window is raised above the MouseFocusClickRaises window without
a focus change, the former top window doesn't get regrabbed, so we won't
catch a click and raise it. This is why I said I'm beginning to think
that button grabs are too tightly bound to focus changing, when they're
equally important to raising/lowering (at least in some cases) - and the
two things don't always go together.

Cheers,
Bob