"Barry A. Warsaw" <bwarsaw_at_anthem.cnri.reston.va.us> writes:
[snip]
> The Fix:
>
> Add another test to the SetFocus() conditional inside the test of
> Event.xany.window == SrcRoot in events.c:HandleEnterNotify() [SEE
> PATCH BELOW]. The only attribute I could find to test on is
> Scr.Focus. During debugging, I noticed that in all bogus cases, the
> SetFocus() clause was not being entered because the test failed. It
> failed because Scr.Focus == 0, which makes some sense. I think the
> only time this happens is when the cursor moves across screen
> boundaries, so I think the change is safe. It does at least seem to
> fix the problem in all situations described above.
>
> I'd love for others with dual-heads to check this out, and if it looks
> okay, *please* for Chuck to add this patch to the final release!
I just tried the patch and it only works a little better for me. It
seems to only do the right thing when there are no windows that accept
focus on the second screen. For example:
screen0: nothing
screen1: xterm
screen2: nothing
If I move the mouse out of the xterm on screen1 and onto screen2, the
xterm cursor is no longer solid and focus appears to really be on
screen2. (I use sloppyfocus)
But, if the screens are like this:
screen0: nothing
screen1: xterm
screen2: xterm
When I move the mouse out of the xterm on screen1 and onto the blank
screen on screen2 (not touching the xterm on screen2), focus is still
in the xterm on screen1.
Anything else I can try?
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Sep 30 1996 - 13:43:45 BST