On Mon, Jun 21, 2004 at 06:01:01PM +0400, Artem Chuprina wrote: > Dominik Vogt -> Artem Chuprina @ Mon, 21 Jun 2004 11:16:49 +0200: > > >> 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? > > 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.
I sse. You are right. [snip] > 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. 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 ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED]
pgpIXwH2gCW5s.pgp
Description: PGP signature
