Subject: Re: xfm and moxfm: Once more unto the breach...

From: Bob Woodside <[email-masked]>
Date: Wed, 01 Aug 2001 23:48:04 -0400

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

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 2 Aug 2001 21:35:26 +0200

> probably me - introduced this symptom before).

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-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: Fri, 03 Aug 2001 01:04:16 -0400

> Anyway, if you send me your sample program I'll have a look at the

	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

---

From: Bob Woodside <[email-masked]>
Date: Sun, 05 Aug 2001 08:33:16 -0400

> 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

---

From: Bob Woodside <[email-masked]>
Date: Mon, 13 Aug 2001 08:21:11 -0400

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

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 13 Aug 2001 13:43:12 +0200

> commit my changes as they stand now, knowing that they will break

No problem.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Fri, 17 Aug 2001 15:18:18 -0400

> 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

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 19 Aug 2001 14:42:22 +0200

> 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 ^_^  ^_^

---

From: Bob Woodside <[email-masked]>
Date: Sun, 19 Aug 2001 13:36:24 -0400

> 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

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 19 Aug 2001 22:33:40 +0200

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

> many!), so it's probably about time to see if other people find problems

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 ^_^  ^_^