Le Sat, 21 Dec 2013 03:11:06 +0100, Dominik Vogt <dominik.v...@gmx.de> a écrit :
> 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. It doesn't work. So, I must think about some kind of bindings editor. Maybe next year. > > -- > Thanks for the in-deep explanation: > 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 ^_^ ^_^ >
