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, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
