> From: Dominik Vogt <[EMAIL PROTECTED]> > Date: Tue, 13 Aug 2002 00:35:04 +0200
> On Mon, Aug 12, 2002 at 06:32:53PM +0100, John Latham wrote: > > After start up, the mouse pointer is always resting over an xterm in my set > > up. Often, but not always, this xterm does not have the focus and I have to > > move the pointer out of it and back in again. This also happens every time > > after a restart when the mouse pointer is resting over a window. In 2.2 and > > previous, the window under the mouse would always get the focus in both > > these > > situations. I have tried this with sloppy and follow-mouse focus, on 2.4.6, > > 2.4.8 and 2.5.2. > For me it works as usual, but it always was always a bit random. > > Maybe the last window created (e.g. Pager or buttons) gets the focus instead > > of the one under the mouse after the restart has finished? > > > > A possible conection: if I PipeRead from FvwmTalk something which destroys > > and > > creates windows (e.g. Pager, Buttons) then after the PipeRead in 2.2 > > FvwmTalk > > still has the focus with sloppy and follows policy, whereas is loses it with > > click focus (as you would expect). However, in 2.4 and 2.5 FvwmTalk has lost > > the focus regardless of policy. (Of course, FvwmTalk has changed so this > > could > > be a red herring). > I recommend to use FvwmConsole instead of FvwmTalk. > > Or, if I select a menu item, which does a PipeRead that causes a new window > > to > > be started (e.g. xbiff), the new window ends up with the focus even though > > the > > mouse is left where it was when it selected the (sub-sub) menu, say now over > > an xterm. In 2.2 the xterm would now get the focus (this is with follow > > mouse/sloppy focus of course). > > > > I have some PipeReads which are executed via InitFunction and > > RestartFunction. > > So, if PipeRead has changed its behaviour in this way, then that could be > > the > > real cause of the start up / restart non-focus problem. > > > > Bottom line: has something like a ``recheck focus policy and current mouse > > position'' operation gone AWOL from the end of a PipeRead? :-) Perhaps > > deliberately changed then -- is that really the best functionality? > It was not reliable in 2.2.x and screwed up some more advanced > functions. Therefore I rewrote the code keeping track of the > focus during function execution to be more reliable, at the cost > of some small changes in focus handling. > > I would > > suggest a good principle: with follows mouse/sloppy focus, if the mouse is > > over a window that can take focus then that window has the focus -- at least > > by the time Fvwm becomes `quiescent' again. > See above. It's almost always easy to restore the focus with the > "Focus" command explicitly in your scripts. Thanks for your clues -- mainly you stopped me looking in the wrong places. I now realise that the lack of focus at start up and after restart was caused by GrabFocus for certain windows being started which were click to focus (e.g. xbiff, pager), even though most were sloppy focus. I just needed to add GrabFocusOff to xbiff, pager etc.. Having thought a little about this, I have a suggestion to make. The default GrabFocus for ClickToFocus and GrabFocusOff for MouseFocus are sensible, only if all windows have the same focus policy. In a mixed policy regime, perhaps the policy of the window which currently has focus should be taken into account before giving focus to a newly created window. I am tempted to suggest another pair of styles called, say, ReleaseFocus and ReleaseFocusOff. ReleaseFocus would be default for ClickToFocus, and ReleaseFocusOff would be default for MouseFocus (and SloppyFocus). A new window would get the focus if and only if it has GrabFocus style, AND the current window has ReleaseFocus style. What do you think? > Bye > > Dominik ^_^ ^_^ Best wishes, John Latham -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
