Well, I survived my first foray into the guts of Fvwm 2.0.43. :-) I
think I killed a major nit with using Fvwm on a dual-headed display
(FTR: Sparc 5, Solaris 2.5, OpenWindows 3.5). The patch seems really
simple and so far I haven't noticed any evil side effects, so I'm
hoping it'll make it into the next major release. I'll first explain
the problem, give the fix, then give a few other comments on Fvwm's
dual-headed support.
The Problem:
On screen 0, bring up an xterm and place it on the root window such
that there are no other windows between it and the edge of screen 1.
You will want focus-follows-mouse mode (note I explicitly do not use
sloppy focus). Put the cursor in the xterm and observe how key press
events properly go to the xterm.
Now start to slide the cursor over to screen 1. It doesn't matter
whether the cursor crosses screen 0's root window or not, but the
cursor should enter screen 1's root window without ever crossing any
other windows on either screen. Start hitting keypresses and watch as
they are bogusly directed to screen 0! Note that if the xterm is
jammed against the side of screen 0, such that moving the cursor to
screen 1 does *not* cross screen 0's root, keypresses in screen 1's
root will get directed to the xterm. If the crossing did cross screen
0's root, the keypresses will be directed to screen 0's root window.
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!
The Patch:
Of course feel free to wax the commentary in this patch. :-) Without
that, its a one line change!
-------------------- snip snip --------------------
*** events.c 1996/09/26 20:40:05 1.1
--- events.c 1996/09/26 23:35:58
***************
*** 1111,1116 ****
if(Event.xany.window == Scr.Root)
{
! if((Scr.Focus)&&(!(Scr.Focus->flags&ClickToFocus))&&
! (!(Scr.Focus->flags&SloppyFocus)))
{
SetFocus(Scr.NoFocusWin,NULL,1);
--- 1111,1125 ----
if(Event.xany.window == Scr.Root)
{
! /* modification: 26-Sep-1996 bwarsaw_at_python.org
! *
! * This change kills one major nit with FVWM on dual-headed systems.
! * The broken behavior was: when a window on screen 0 had the focus,
! * and the cursor was moved to the root window of screen 1, all
! * keypress events would still get delivered to screen 0.
! */
! if(!Scr.Focus ||
! ((Scr.Focus)&&
! (!(Scr.Focus->flags&ClickToFocus))&&
! (!(Scr.Focus->flags&SloppyFocus))))
{
SetFocus(Scr.NoFocusWin,NULL,1);
-------------------- snip snip --------------------
More on Dual-Headedness:
I still think ctwm 3.3 handles dual-headedness better than Fvwm.
During debugging of this problem I noticed that the way Fvwm handles
the presence of multiple screens is to fork off a clone of itself for
each screen. I surmise this is primarily because there is only one
global ScreenInfo structure, and so much of the code refers to it
through Scr.<whatever>.
I quickly peeked at ctwm's startup and noticed it doesn't do things
this way. It actually has an array of ScreenInfo's, one for each
screen, and the global Scr is a pointer into this array. So it
accesses the current screen with Scr-><whatever>. So there is only
one ctwm process (no forking), and I think that makes more sense.
I'm sure the differences are somewhat more substantial, but I didn't
look into it in great detail. As it stands (with this patch), Fvwm is
much more usable now. Certainly such restructuring needn't happen
until after the next major release, but I wanted to bring your
attention to the difference. Hopefully this can be improved in the
future. I'd say, rip off as much from ctwm as possible. In all other
respects, Fvwm is a better window manager.
Thanks, and keep up the great work!
-Barry
[P.S. Some time, I'll post my thoughts on integrating a Python
interpreter into Fvwm, a la PyApache, the HTTP server with an
integrated Python interpreter]
--
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 Thu Sep 26 1996 - 19:04:38 BST