Matevz Tadel wrote:
Thomas Adam wrote:
2009/1/28 Matevz Tadel <[email protected]>:
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.
Again, having tried this with Firefox, where I deliberately clicked on
a hyperlink, the window was not raised. The same thing happened using
your broken config (I say "broken", the syntax for conditional
commands and modules is *out* of date.)
Thanks, I believed you the first time :) Will fix the syntax, sorry
about that.
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.
Yes, this is exactly what I would expect to see.
Are you sure, because this is definitely not what I'd expect?
I tried with kde and gnome (fedora 10, my desktop where I get this
issue), fvwm-2.4.19 (fedora 7) and asked a friend who runs fvwm-2.5.26
(gentoo). On all this systems xev reports the following sequence for M1
click:
a) outside the "grab rectangle"
ButtonPress ButtonRelease
b) within the "grab rectangle"
ButtonPress EnterNotify KeymapNotify ButtonRelease LeaveNotify
On my machine with fvwm I get:
a) LeaveNotify EnterNotify KeymapNotify ButtonPress ButtonRelease
b) ButtonPress EnterNotify KeymapNotify ButtonRelease LeaveNotify
Note that in case a) Leave/EnterNotify are sent before the ButtonPress.
If this is truly the expected behaviour, can you please point me to the
code in fvwm that causes it.
By commenting out parts in my config, I traced this down to the following lines:
Mouse 1 W M FuncFvwmRaiseLowerX Move
Mouse 2 W M RaiseLower
Mouse 3 W M FuncFvwmRaiseLowerX Resize
I understand that the grab must be called if a function is called ... but in
this case the grab happens even when no modifier keys are pressed.
Is it possible to extend the grab-check to also consider the modifier mask? I'd
gladly do the first implementation if somebody can help me get started, please.
This still doesn't solve the !FPPassRaiseClick ... but the grab issue is in fact
more important to me as it prevents me from interacting with a GL application
that drops its selection state on LeaveNotify.
Best,
Matevz
