> >I'm not going to break > >other applications by changing fvwm to what you think is right. > > > > The matter is not what I think is right. The matter is > HOW to 'Use NorthWestGravity, not StaticGravity' in the > configuration file fvwm2rc.
The gravity is set by the application, not by the window manager. So, if fltk does not use NorthWestGravity, then change fltk or use something else. > Searching in FLTK-1.3 I found that in fact the values > > attr.bit_gravity = 0; // StaticGravity; 7:NorthWestGravity > hints->win_gravity = StaticGravity; // NorthWestGravity > > are used. After replacing bit_gravity with 7 and win_gravity > with NorthWestGravity, the window in question showed up as > wanted. If fltk-1.3 relies on poorly defined behaviour, then that's fltk's problem, not fvwm's. The only way to fix that is to change fltk. There's no possible sensible reason to use StaticGravity on all windows, and in many cases it's really just broken. If an applications wants to keep the top left corner of the window at the same position when it's resized, just use NorthWestGravity. That's what NorthWestGravity is meant for. The meaning of StaticGravity is only properly defined if just the decorations of a window change, but the contents stay the same (and are not resized). Practically, when a window with StaticGravity is in fvwmresized, it keeps the center of the client window at the same place. Other window managers keep the top left corner of the client window in place, which is equivalent to NorthWestGravity unless the decorations of the window change. StaticGravity should really never be used unless you have a really good reason to care about the size and placement of the window decorations, and even then it's probably just a bug in the application. StaticGravity during resize is not really standardized anyway. > HOW must run the line(s) in fvwm2rc to change these values? Fvwm (or any other window manager) cannot override the application window's gravity. Ciao Dominik ^_^ ^_^
