Dominik Vogt wrote: > On Thu, Jun 19, 2014 at 04:59:59PM +0100, Klaus Ethgen wrote: >> There are several applications that steal away complete key control from >> fvwm so no key bindings works if the window has the focus. Example are >> kvm, spicec or several java tools that capture the whole input. >> Unfortunately that left me with being unable to switch the desks or lock >> the screen or other stuff that I bound to keys in fvwm. >> >> Is there any way to get around that problem and allow fvwm to react to >> key bindings even if the bold window/application has the focus? > > Sadly, there is no way to prevent applications from grabbing all > keyboard input if they want to. The X protocol does not allow the > window manager to intervene in any way. To fix this, all you can > do is to complain to the vendor to change this. :-( > > Well you could try to run a nested X server in a window with xnest > and then run the annoying applications in there. I'm not sure > whether this works, but it's worth a try.
The big disadvantage of xnest et cetera is that there is no clipboard between the applications on the main X server on one side and the nested applications on the other side. It prevented me to use nested X servers years before, because applications without clipboard connection do not make sense, but I didn't make a large-scale, time consuming action to investigate if clipboards are nevertheless exist, with a trick somehow. >> Similar is the problem of applications to decide them self where to map >> to. You can apply the style 'StartsOnPage 2 0, SkipMapping', but firefox >> does remap themself directly after the start so the window will end on >> the current page. >> >> I miss some style settings to disallow applications to act that bold. > > If Firefox really moves the windows around after initial mapping, > the following styles should do the trick: > > Style <stylename> FixedPPosition > > If the window is also mapped at funny places, one of the following > two styles whould help: > > Style <stylename> !UsePPosition, !UseTransientPPosition > Style <stylename> !UseUSPosition, !UseTransientUSPosition > > If that does not help, please explain the behaviour that annoys you > in more detail. Note that the initial position of a window is > affected by different styles than the styles used to prevent the > application from doing funny things _after_ the window has become > visible. It is not difficult to override the initial position of > a window, but unfortunately there is a plethora of ways in which an > application can change the position of a window afterwards. > > Hm, maybe fvwm should just have a style "DoWhatISay" that would > disable all the freaky, unexpected behaviour that annoys user so > much. ;-) > > Ciao > > Dominik ^_^ ^_^ >
