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.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, dominik.vogt_at_gmx.de
Reply-To: dominik.vogt_at_gmx.de
--
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 Mon Aug 12 2002 - 18:13:46 BST