On Tue, Aug 20, 2002 at 04:15:59PM +0100, John Latham wrote:
> > From: Dominik Vogt <dominik.vogt_at_gmx.de>
> > 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: dominik.vogt_at_schlund.de, 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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Aug 20 2002 - 10:27:08 BST