I seem to be having a lot of difficulty understanding what you're telling me. If you want me to reply off list (so as not to bore everyone else) let me know.
> > > Style window_at_bottom SloppyFocus, GrabFocus > > > Style window_at_top NeverFocus, PositionPlacement x y > > > > > You might have to sort the ordering out yourself as to when/where these > > > windows are mapped, > > > and in what order. I've given you an example of PositionPlacement, so > > > > I've tried what you gave above (except with no ", PositionPlacement x y" > > Right -- I thought you said this top window was alwas over the bottom window > which is to have the focus? That's correct. I just don't understand why there is "PositionPlacement" there. That should just put the widget at that spot right? Does it change focus behavior? I did add it back in (with "10 10" for the x y) but still notice the same behavior (the lower window doesn't regain keyboard focus until I slew out of the top window. > Style bottom_window InitialMapCommand Focus NoWarp, StartsOnPage x y, \ > SkipMapping > > then you can always do something like this: > > DestroyModuleConfig FE-PW:* > *FE-PW: enter_window SomeFunc > > AddToFunc StartFunction I Module FvwmEvent FE-PW > > DestroyFunc SomeFunc > AddToFunc SomeFunc > + I PointerWindow (top_level_window_class_name) \ > Next (my_bottom_win_name, AcceptsFocus, !Focused, CirculateHit) Focus > NoWarp I did change "bottom_window" to be the "class" of my bottom window likewise with "my_bottom_win_name", and made "top_level_window_class_name" to be the top window class name. Otherwise, I literally wrote in what you gave. Should I chage InitialMapCommand to be "FE-PW" or "SomeFunc"? > But I am still not sure what effect it is you're after from that point on. I want everything typed by the keyboard to go to the "bottom widget" never the "top" one (even if the mouse is above the top one or is clicking on the top one). So far, I'm happy with the pointer behavior, but the best solution I have (the first one you gave) I still have to move the pointer so it is no longer above the top window before the bottom window regains keyboard focus. > Is it the case that this top window which has NeverFocus set on it is always > responsible for providing focus to the bottom window? That's probably the only way for a window manager to give keyboard focus to a GUI that is obscured (have the window on top pass it to the window on bottom). > then you can always do something like this: > > DestroyModuleConfig FE-PW:* > *FE-PW: enter_window SomeFunc > > AddToFunc StartFunction I Module FvwmEvent FE-PW > > DestroyFunc SomeFunc > AddToFunc SomeFunc > + I PointerWindow (top_level_window_class_name) \ > Next (my_bottom_win_name, AcceptsFocus, !Focused, CirculateHit) Focus > NoWarp I put this bottom part in literally (only changing "top_level_window_class_name" and "my_bottom_win_name"- to the respective class names). When I reloaded fvwm was not working properly (either some of the things I left out that I thought were optional weren't or I did substitutions wrong (like "InitialMapCommand"). I seem to be getting more confused the more I play around with this. It seems
