Subject: FVWM: FwvmAuto(?) & focus

From: Artem Chuprina <[email-masked]>
Date: Fri, 11 Jun 2004 22:03:25 +0400

Sorry if I failed to find it elswhere.

fvwm 2.5.10

Excerpt from .fvwm2rc (I hope that's all that may be relevant):
Style "*"	SloppyFocus, MinOverlapPercentPlacement
Style "*"	ClickToFocusRaises, ClickToFocusPassesClickOff

AddToFunc StartFunction
+ "I" Module FvwmAuto 1000
+ "I" Module FvwmCommandS
+ "I" Module FvwmEvent FvwmEventNewWindow

*FvwmEventNewWindow: StartDelay 4
*FvwmEventNewWindow: add_window FocusAndRaise

The problem: if some window is overlapped by another, application in it
does not get mouse input until a window is raised (either by FvwmAuto or
by any other means).  But it does get keyboard input.

In fvwm 2.4.16 with identical configuration this problem does not
appear.  Maybe some defaults have changed?

-- 
Artem Chuprina
RFC2822: <[email-masked]>, FIDO: 2:5020/122.256, ICQ: 13038757
--
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-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 21 Jun 2004 11:16:49 +0200

> appear.  Maybe some defaults have changed?

The behaviour you see is exactly what you are asking for.  With

                                                       ^^^

you're telling fvwm not to pass any clicks on lowered windows to
the application, and this is what you get.  I didn't check 2.4.16,
but if it does not work as described, there is a bug in 2.4.x, not
in 2.5.x.  Try

  Style * ClickToFocusRaises, ClickToFocusPassesClick

instead.  (Note that double quotes around style names are only
necessary if the style contains whitespace or quoting characters).

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Artem Chuprina <[email-masked]>
Date: Mon, 21 Jun 2004 18:01:01 +0400

>> appear.  Maybe some defaults have changed?

 DV> The behaviour you see is exactly what you are asking for.  With

 DV>   Style "*" ClickToFocusRaises, ClickToFocusPassesClickOff
 DV>                                                        ^^^

 DV> you're telling fvwm not to pass any clicks on lowered windows to
 DV> the application, and this is what you get.  I didn't check 2.4.16,
 DV> but if it does not work as described, there is a bug in 2.4.x, not
 DV> in 2.5.x.

No, if it is so, it is a bug either in name of parameter or in 2.5.x.
It is not a click to focus.  These windows have SloppyFocus style, not
ClickToFocus.  And well, for ClickToFocus windows (now I have no such) I
would not want passing of click.

In 2.4.x behavior is as described:

"ClickToFocusPassesClickOff and ClickToFocusPassesClick controls if a
mouse click to focus a window using the ClickToFocus model is sent to
the application or not"

means that it does not affect non-ClickToFocus windows.

Well, in 2.5.x manpage I found

"ClickToFocusPassesClickOff and ClickToFocusPassesClick controls if a
mouse click to focus a window using the ClickToFocus model is sent to
the application or not. Similarly,
ClickToFocusRaisesOff/MouseFocusClickRaisesOff and
ClickToFocusRaises/MouseFocusClickRaises control if the window is
raised.

Note: in fvwm versions prior to 2.5.3, the "Click..." options applied
only to windows with ClickToFocus while the "Mouse..." options applied
to windows with a different focus policy. This is no longer the case. "

But as I can see, the second paragraph contradicts the first one.  And
then what's the sense of such a change in logic?  From my point of view
this is definitely a mistake.  Well, I know workaround (for each window
window with ClickToFocus style also explicitly set
ClickToFocusPassesClickOff), but what if in 2.6.x there will be
analogous strange logic in this place?

 DV> Try

 DV>   Style * ClickToFocusRaises, ClickToFocusPassesClick

 DV> instead.  (Note that double quotes around style names are only
 DV> necessary if the style contains whitespace or quoting characters).

Sorry, I have not tested this on 2.5.x yet.  If test will fail, I'll be
back :-)

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 21 Jun 2004 17:23:50 +0200

> would not want passing of click.

I sse.  You are right.

[snip]

> But as I can see, the second paragraph contradicts the first one.

I made it a bit clearer.

> And then what's the sense of such a change in logic?

The focus code was completely rewritten and cleaned up.  As a
consequence, the old focus related options have become obsolete.
They were replaced by an awful lot of new styles, all beginning
with "FP".  One result of cleaning up was that the focus model
type has vanished from the style names.  As a side effect, fvwm
can't distinguish between a "click to raise" on a SloppyFocus
window and on a ClickToFocus window anymore.

I tried my best to not change any existing behaviour, but in some
rare cases that could not be done.  Sometimes I had to choose
between compatibility and streamlining the set of options.

> From my point of view this is definitely a mistake.  Well, I
> know workaround (for each window window with ClickToFocus
> style also explicitly set ClickToFocusPassesClickOff),

Actually, from the day the focus logic was rewritten, this is the
correct (and now documented) way to achieve the effect you want.

> but what if in 2.6.x there will be analogous strange logic in
> this place?

I hope you understand the logic from my explanation.  Usually,
we're not changing traditional fvwm behaviour just for the kicks,
but sometimes it's compatibility versus progress.  Behaviour in
2.6 is going to change as little as possible.  There are some
things that do change (all of which are easy to circumvent with a
configuration change), and you can be sure I am painfully aware of
them (of course I had forgotten this one).

Ciao

Dominik ^_^  ^_^