Subject: window under mouse doesn't get focus at startup

From: Austin Donnelly <[email-masked]>
Date: Sat, 8 Nov 1997 14:52:57 +0000 (GMT)

An old chestnut, I'm afraid.

It seems people aren't too happy about fvwm2's behaviour of not giving
focus to the window that's under the cursor during startup.  Any
chance of a fix, or should I look into this myself?

Austin

Subject: possible problem with fvwm2
From: James A. Treacy <[email-masked]>
To: [email-masked]
Date: Fri, 7 Nov 1997 11:17:45 -0500 (EST)

I'm writing directly to you instead of filing a bug as this is
probably something that can be fixed using the startup scripts.
When I start X, I don't get focus in the window the mouse is
currently in when using fvwm2. This is rather annoying as I
like to start typing as soon as I start X and having to move
the mouse first is driving me crazy. Ok, it's not that serious. :)

- Jay

---

From: Bob Woodside <[email-masked]>
Date: Sun, 09 Nov 1997 14:47:57 -0500 (EST)

>chance of a fix, or should I look into this myself?

        I've been tinkering with the focus code (for other reasons), and 
I'd be willing to look at this as well while I'm in the code...

        The "fix" seems superficially easy - there's an XSetInputFocus to
the dummy NoFocus window at startup, and removing it seems not to cause 
any grief. This gives the result your user seems to want, *if*....

        The "if" is this: if your user uses *all* mouse focus and no
click focus windows, he should be happy. However, each time a ClickToFocus
window gets created, it has the focus given to it (this is the area I've
been looking into), so if your user uses a mix of focus policies, the
window under the mouse could still get the focus taken away by a clicky 
window, depending on the order of events at startup.

        I don't see a universally acceptable way of resolving this 
potential conflict without adding yet another option, which I'd hoped not
to do - I wanted to try sending Chuck a *small* patch for a change.  :-)
I'll have to give this a little more thought.

        If your users can live with the simple version, I'll be happy to
pass the one-liner along.

        - Bob

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Greg Badros <[email-masked]>
Date: 09 Nov 1997 12:23:00 -0800

Austin Donnelly <[email-masked]> writes:

> --Ag3Al2wSc2
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 

I've fixed this for SCWM (Scheme Configurable Window Manager) which
started out descending from fvwm2 code; though I don't have a patch
specific to fvwm2, here's what works for me:

In the main() function, just after UnBlackoutScreen(), and before the
HandleEvents() call,  call a new function "CoerceEnterNotifyOnCurrentWindow()".
That function (can throw it in misc.c, if you like) looks like this

/* CoerceEnterNotifyOnCurrentWindow()
 * Pretends to get a HandleEnterNotify on the
 * window that the pointer currently is in so that
 * the focus gets set correctly from the beginning
 * Note that this presently only works if the current
 * window is not click_to_focus;  I think that
 * that behaviour is correct and desirable. --11/08/97 gjb */
void
CoerceEnterNotifyOnCurrentWindow()
{
  extern ScwmWindow *swCurrent; /* from events.c */
  Window child, root;
  int root_x, root_y;
  int win_x, win_y;
  Bool f = XQueryPointer(dpy, Scr.Root, &root,
			 &child, &root_x, &root_y, &win_x, &win_y, &JunkMask);
  if (f && child != None) {
    Event.xany.window = child;
    if (XFindContext(dpy, child, ScwmContext, (caddr_t *) &swCurrent) == XCNOENT)
      swCurrent = NULL;
    HandleEnterNotify();
    swCurrent = None;
  }
}

Note that swCurrent is called Tmp_win in fvwm2, I believe.  Some of the
other variable names have changed (ScwmContext probably was FvwmContext,
I'd guess).

Let me know if this isn't obviously workable in fvwm2...

Greg J. Badros
[email-masked]
Seattle, WA  USA
http://www.cs.washington.edu/homes/gjb

---

From: Bob Woodside <[email-masked]>
Date: Sun, 09 Nov 1997 22:15:23 -0500 (EST)

On 09-Nov-97 Greg Badros wrote:
gjb>>  In the main() function, just after UnBlackoutScreen(), and before the
gjb>>  HandleEvents() call,  call a new function
gjb>>  "CoerceEnterNotifyOnCurrentWindow()".
gjb>>  That function (can throw it in misc.c, if you like) looks like this

        Thanks, Greg. This does the trick nicely. After my last post, I'd
been toying with putting the XQueryPointer and another XSetInputFocus 
inline in main(), but I like your approach better.

        I put a patch modified for fvwm-2.0.46 in the incoming directory,
under the name MouseFocusOnStartup.patch. so it should show up in 
the version-2/unofficial_patches directory soon.

        - Bob

---

From: Dan Espen <[email-masked]>
Date: Mon, 10 Nov 1997 11:08:20 -0500

> pass the one-liner along.

Glad to  hear you are looking  at the focus code.   I find the loss of
focus during startup to be mildy annoying and I am glad you have found
a fix for the problem.

Even more annoying is the way nothing gets focus after certain windows
are closed.  For example, when the Netscape  window is closed, and the
pointer lands on  the  root window, mouse  movement  in and out   of a
window is required to get root window keybindings to start working.

(I use Style "*" MouseFocus)

I suspected that the "no focus  window" had something  to do with this
also, but  had difficultly following the  related code.  Hopefully you
could look at this problem also?

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Mon, 10 Nov 1997 22:36:36 -0500 (EST)

> could look at this problem also?

        Aww...just when I thought I had a nice small patch all wrapped 
up!  :-)

        Actually, I think I'd better wrap up the PleaseDontStealMyFocus
patch and send it to Chuck, and work on this as a separate item. Your 
problem looks like it may take a little more research.

        You're quite right that the NoFocus window is getting into the
act. When a window unmaps, if fvwm can't find a likely focus candidate 
next in the window chain, it gives focus to the NoFocus window. Hmmm...
wonder what would happen if we tried giving it to the root window instead?
Anybody been there already...?

        I'll definitely look into it.

        - Bob