2009/8/18 Viktor Griph <gr...@dd.chalmers.se>: > 2009/8/18 Thomas Adam <thomas.ada...@gmail.com>: >> 2009/8/18 John H. Moe <john...@optushome.com.au>: >>> The only thing I can add is that it *seems* to happen after I launch my >>> first KDE app (like KNetwalk, Kopete, K3B), but only sometimes. And if >>> the first one doesn't cause it, then it seems none do. From what I >>> understand, KDE apps have a few libs and/or programs that need to run in >>> the background to work properly, and once they're loaded they stay >> >> I suppose it's possible that some components of KDE are being loaded >> which are intercepting key events -- GNOME can do this for instance >> with its key-binding manager for multimedia keys which also let you >> bind other keys -- FVWM never gets the event for this, and so the >> effect is as you describe. Perhaps KDE do something similar? I >> wouldn't know, nor care. > > I suspect that KDE remaps the keyboard on start. > Compare the output of "xmodmap -pm" before and after you start KDE > apps. If there are any changes at all to the output then that might > explain the issue. There may also be other changes to the keyboard > mapping that's going. FVWM does not respond to changes in the keyboard > mapping after it has been launched.
Well, it does take note of MappingNotify, it just doesn't remap the key bindings IFF the layout changes -- and I was talking to someone the other day who wanted to do this -- but I am not convinced we *should*. There's various reports of people complaining that with recent Xorgs, the keyboard mapping happens to "quickly", with FVWM realising a keyboard layout of "US" initially, but then the XServer changing it from under its feet -- effectively making any bindings void until FVWM is restarted (when it gets the correct keyboard layout). -- Thomas Adam
