On Tue, Aug 20, 2002 at 04:15:59PM +0100, John Latham wrote: > > 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.
They already exist in 2.5.3-devel: FPGrabFocus FPGrabFocusTransient FPOverrideGrabFocus FPReleaseFocus FPReleaseFocusTransient FPOverrideReleaseFocus > 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. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- 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]
