On Sat, Dec 21, 2013 at 01:20:16AM +0100, Dominique Michel wrote: [snip] > But if I want to remove it only when a window of class Ardour have the > focus and I run > > Key B A M Music-Next > Key (Ardour) B W M - > > it do nothing and Alt+B call Music-Next in any case, even when Ardour > have the focus.
That's not the way removing bindings works. You can only remove a binding completely or not at all. It's not possible to partially remove a binding just for selected windows. > I try the same thing with the name, class and resource > of an urxvt term with the same result: the binding is not removed when > the window have the focus. That does not work and was never intended to work. There is some obscure feature in the binding code that instructs fvwm to pass a keystroke to the underlying window if there is a binding with the action "--" (without the quotes), but on one hand the code has a bug (i.e. it does not work), and even if the bug is fixed, I see no way how it could work. -- Fvwm intercepts the defined key bindings on _all_ windows because otherwise key bindings on unfocused windows might not work (PointerKey command). Now, there _is_ code that detects that fvwm got a key press event on a window for which it has no binding, but then the damage is already done. events.c:__handle_key() makes a feeble attempt to pass the intercepted key event to the window that may or may not work. The normal sequence of events a window gets is KeyPress (non-synthetic) KeyRelease (non-synthetic) With the "undone" interception it gets FocusOut (NotifyAncestor) KeyPress (synthetic) FocusOut (NotifyPointer) FocusIn (NotifyAncestor) KeymapNotify (non-synthetic) KeyRelease (synthetic) So, on one hand the window gets synthetic events which some or maybe even many applications refure to handle, and on the other hand the KeyPress arrives during the grab, while the window has lost the focus. There's nothing we can do about the synthetic events, and I cannot think of a way to terminate a passiv grab early, i.e. before the grabbed key is released. If there was such a way, then the window would get the FocusIn evens _before_ the synthetic KeyPress which should improve the chance that the application actually uses the KeyPress. I can think only of one way to really fix this. We'd have to re-grab all bindings on all windows (1) whenever the focus changes (Focus... events or fvwm sets focus) and (2) whenever the pointer crosses any window borders (including unmanaged windows) (i.e. EnterNotify and LeaveNotify events). However, for remote servers on slow connections this would be _slow_ (including dead modifiers a complex fvwm configuration may have hundreds or thousands of grabs per window). To sum it up: At the moment I've no idea how this can be fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
