Subject: FVWM: ClickToFocus feature wish or question

From: Kai Grossjohann <[email-masked]>
Date: 30 Oct 1996 13:40:34 +0100

Hi all,

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

How do I turn off (2)?  I don't want my Emacs to do strange things
just because I click in it to give it focus!

The behavior for a click in a window should be this:

    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.

tia,
kai
-- 
Life is hard and then you die.
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Michael Tiefenback <[email-masked]>
Date: Wed, 30 Oct 1996 09:36:35 -0500 (EST)

On 30 Oct 1996, Kai Grossjohann wrote:

> [...snip...]

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

---

From: lar3ry gensch <[email-masked]>
Date: Wed, 30 Oct 1996 09:23:45 -0500

> just because I click in it to give it focus!

The Motif Window Manager has the properties passButtons and
passSelectButton to enable/disable this feature.  It seems to me like
fvwm should have a similar Style or keyword.

I use ClickToFocus all the time with fvwm and have learned (the hard
way!) to click on an "appropriate" area of a window that I want to
raise.  This is especially important in text editors where I could
possibly lose my cursor position [frown].

-- 
------------------ http://www.tiac.net/users/lar3ry/ -------------------
(void) lar3ry();                                      [email-masked]

  "I'll only enjoy being a manager when they port gdb to debug humans"