On 30 Oct 1996, Kai Grossjohann wrote:
> due to the long discussion with Scott on the relative merits of
> ClickToFocus and FocusFollowsMouse, I tried to turn on ClickToFocus
> just to try it out. I turned of off again after 10 seconds, though,
> due to the following problem:
>
> The first click in a window does two things:
>
> (1) it gives the window focus
> (2) it is passed on to the application
> [...snip...]
> If the window has focus already, pass the click on to the
> application. Otherwise, give focus to the window and forward the
> click to /dev/null.
>
> Also, when I click on the title bar of a window that is below and
> doesn't have focus, it is first raised then lowered again. This
> problem could be solved with the same behavior, if Fvwm were to eat
> the focus-giving click, the window wouldn't be lowered.
I sent the following to the list a few days ago:
ME> [...snip...] but when I have ClickToFocus set for a window, I get the
ME> following behavior [mouse 3 tied to RaiseLower]
ME> Window has focus click 3 in Title RaiseLower toggle
ME> Window has no focus click 3 in Title Window Raises briefly
ME> above any windows it
ME> had been below, then
ME> drops to bottom.
ME> [...snip...] This seems to be due to the ClickToFocus generating a Raise
ME> event before evoking the RaiseLower which then drops the window to the
ME> bottom. I *really* like fvwm, and I don't consider this a real problem,
ME> but neither do I consider it to be proper behavior, as the Raise is not
ME> called out in the manpage as a result of a window-click, at least as far
ME> as I have found. Is this related to the relatively nasty behavior I see
ME> with some Motif processes (getting a Raise command [dutifully executed]
ME> resulting from a button-click which was issued to call forth a menu
ME> in the window _body_ [note: menus from menubar work properly], thus
ME> covering up the newly created menu)? [...snip...]
I would really like to get the Motif window-click menu problem solved, and
Scott Raney's observation about configureNotify events is the most
relevant-sounding bit of info I have heard (although I suspect it would
only lead to the general area in the code from which the bothersome
behavior comes, rather than being from the same cause). In my problem
instance, the menu click passed on to the app invokes a Raise whether the
window is on top or not, and generally (although in some highly loaded
cases on my Linux box this behavior is not universal, indicating the
generally undesirable existence of a race condition) after the menu has
been invoked. This problem would persist even with Kai's proposed change.
The raise event seems to come from the app, and is handled in an
acceptable sequence by mwm and vuewm, but not by fvwm and twm. Does mwm
really ignore menus (as fvwm seems to do) or does it subtly give them
favored status by keeping them on top? If fvwm were to handle them with a
StaysOnTop style, then my immediate irritant might go away (leaving a
residual hackish aftertaste). However, I don't know how to query the
system for window info for a menu, because the focus event required to
bring up the query function causes the menu to go away.
Why does the ClickToFocus automatically come with a window raise, anyway?
When I click in a ClickToFocus window which already has focus, it does not
raise. The only thing I can find related to this is an oblique reference
in the Focus command, where the manpage states that execution of the Focus
command will raise the window "if needed to make it visible." I presume
this means if any part of it is covered, rather than if no part of it is
visible. This is too generally useful for finding windows for me to
suggest changing, but if a non-raising focus alternative were available
for use by ClickToFocus, it might solve *some* problems.
My apologies if this is overly long...a global tiefen-property, it seems
at times...
Michael Tiefenback
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Oct 30 1996 - 08:31:35 GMT