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]
