FVWM: Multi-screen patch redux

From: Barry A. Warsaw <bwarsaw_at_anthem.cnri.reston.va.us>
Date: Thu, 20 Feb 1997 17:14:38 -0500

On 26 Sep 1996, I posted a patch to fix a problem with handling focus
on multiple screen systems. The problem manifested itself when moving
the pointer from a window on e.g. screen 0 to the root window of
screen 1. In these situations, screen 0 would still get focus. See
my message of that date for details.

The fix was simple, I thought. But then on 30 Sep 1996, Mark Boyns
followed up with a note that under SloppyFocus there were focus
problems with my patch. Chuck subsequently did not install my patch
in 2.0.45.

I've just spent some time tracking all this down, and I now think that
Mark's problem has nothing to do with my patch (sorry Mark ;). I
think the SloppyFocus problem exists in 2.0.45 with or without my
patch. I'd like Mark (or any other multi-screener) to verify, but I
have been able to reproduce the problem from Mark's description with a
vanilla 2.0.45. My patch does nothing to fix or hurt this, AFAICT.

I've also come to the conclusion that really good multi-screen support
is hopeless with the way FVWM currently handles multiple screens. I
don't think there's any way for the screen 0 process to know what's
happening on screen 1 and vice versa. And if you wanted SloppyFocus
to work correctly, it would have to do this:

    - when moving the pointer from a window in screen 0 to the root
      window in screen 1, the original window keeps focus

    - when subsequently moving the pointer to a window in screen 1, it
      gets focus and the original window loses focus.

    - when moving the pointer from a window in screen 0 to a window in
      screen 1, the new window gets focus and the original window
      loses it.

I don't think there's any way to do this because the screen 0 process
never gets EnterNotify events on screen 1, so it will never know
exactly when to de-focus the original screen. It could be that there
are dark corners of X (or the FVWM sources :) that contain the answer,
but I can't find it, and can't really spend any more time on the
problem. The ultimate fix is to do what ctwm does and *not* fork a
separate FVWM process for every screen. That'll take a major effort I
think.

So, I'm reposting my patch (actually a little cleaner this time), and
hope Chuck will put it in the next version. If not, I'll resign
myself to patching subsequent versions myself...

-Barry



*** events.c 1997/02/20 16:09:23 1.1
--- events.c 1997/02/20 21:34:48
***************
*** 1100,1105 ****
    if(Event.xany.window == Scr.Root)
      {
! if((Scr.Focus)&&(!(Scr.Focus->flags&ClickToFocus))&&
! (!(Scr.Focus->flags&SloppyFocus)))
          {
            SetFocus(Scr.NoFocusWin,NULL,1);
--- 1100,1105 ----
    if(Event.xany.window == Scr.Root)
      {
! if(!Scr.Focus || (!(Scr.Focus->flags&ClickToFocus)&&
! !(Scr.Focus->flags&SloppyFocus)))
          {
            SetFocus(Scr.NoFocusWin,NULL,1);

--
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 Feb 20 1997 - 16:19:47 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:38:00 BST