Thomas Adam wrote:
2009/1/28 Matevz Tadel <[email protected]>:
Hi,
I'm trying to convince fvwm to not pass the click that raises the window to
the application:
Style * SloppyFocus
Style * FPClickRaisesFocused
Style * !FPPassRaiseClick
Style * FPIgnoreRaiseClickMotion
Full config file: <http://mtadel.home.cern.ch/mtadel/fvwm-iconman/fvwm2rc>
I thought that '!FPPassRaiseClick' would do the trick, but it seems to have
no effect. Is this due to interaction with sloppy-focus?
No effect how? It works fine. For example, if I apply:
Style * FPClickRaisesFocused
Style * !FPPassRaiseClick
(I already use SloppyFocus). and then load gvim and within that do:
:set mousemodel=popup
That would ordinarily force a popup menu if I were to right-click on
the gvim window. Instead, that action never happens because the click
is never sent to Gvim; the window is raised instead.
Setting:
Style * FPPassRaiseClick
Back to how it is by default and right-clicking on Gvim raises the
window *and* this time passes the click through to enable the popup
menu.
As expected.
For example:
- windows obscure thunderbird window;
- I move the mouse into the thunderbird window, it receives focus;
- I click M1, thunderbird raises but also processes the click,
selecting the message/folder that was below the mouse, which
is exactly what I'm trying to avoid.
So it must be another thing. I've noticed that mouse click always sends the
following event sequence (using xev):
KeymapNotify, LeaveNotify, EnterNotify, ButtonPress, ButtonRelease
even when I'm not in the "grab rectangle" of xev.
I tried the same with window managers used by KDE and GNOME and they deliver
ButtonPress/ButtonRelease only, as expected. So it seems this is not an X thing.
Is it possible that something in my fvwmrc causes this behaviour?
Thanks,
Matevz
