Re: FVWM: No focus on start up?
> Date: Tue, 20 Aug 2002 17:25:59 +0200 > From: Dominik Vogt ... > > 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 ... Excellent!! I promise when I get a bit settled work wise (...), I'll start using the devel versions for personal use so I might be more useful to you. > Bye > > Dominik ^_^ ^_^ Best wishes, John Latham -- Visit the official FVWM web page at 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]
Re: FVWM: No focus on start up?
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 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]
Re: FVWM: No focus on start up?
> 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 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]
Re: FVWM: No focus on start up?
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 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]
FVWM: No focus on start up?
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. 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). 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? 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. Best wishes, John Latham -- Visit the official FVWM web page at 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]
