Re: Another key binding issue
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 ^_^ ^_^
Another key binding issue
Now I have another key binding issue. If I have an assigned binding with: Key B A M Music-Next It call the function Music-Next when I press Alt+B. That work fine. If I remove it with Key B A M - That work fine too, Alt+B is doing nothing, and when in Ardour I can use Alt+B to fire and close its big clock. 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. 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. Same result with Key (Ardour) B A M - Also, I try with fvwm-2.6.5, and the problem is different, I must use function , the binding is removed when in Ardour, but Ardour's own function is not restored. This was working in 2007: https://mail.gna.org/public/fvwm-crystal-users/2007-03/msg6.html Dominique
Re: Another key binding issue
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
