Dominik Vogt <[email protected]> writes: > On Thu, Aug 23, 2018 at 07:10:47PM +0200, hw wrote: >> Hi! >> >> Fvwms manpage says: >> >> >> Placement policy options and window stacking >> !UsePPosition instructs fvwm to ignore the program >> specified position (PPosition hint) when adding new >> windows. Using PPosition is required for some >> applications, but if you do not have one of those it's a >> real headache. Many programs set PPosition to something >> obnoxious like 0,0 (upper left corner). Note: >> !UsePPosition is equivalent to the deprecated option >> !UsePPosition >> >> >> Is "!UsePPosition" deprecated? > > No, it just means that styles nowadays are all negated with a '!' > in front of them and the old names with "No..", "Dont..." etc. > shouldn't be used anymore. There's a type though; the manpge > should state that "NoPPosition" is deprecated.
Should make a bug report? >> Some years ago, I had found out that I need to use "FixedPPosition" for >> Seamonkey to prevent it from creating windows at unreachable places, >> i. e. way off screen on desktop pages that didn't even exist. So I??m >> using this option for Firefox now. >> >> What option(s) can I use to prevent windows being created by Firestorm >> at unreachable places and yet have them placed according to the >> placement policy? > > Well, the full array of options to get shitty applications under > control is: > > Style ... fixedpposition, fixedusposition > Style ... fixedpsize, fixedussize > style ... gnomeignorehints, EWMHIgnoreStackingOrderHints > style ... EWMHIgnoreStrutHints, EWMHPlacementIgnoreWorkingArea > style ... EWMHIgnoreStateHints > > (The fixedus... styles make it impossible for the user to move or > resize the window too. If they re the only way to make the > application behave, one could make a script that waits for a few > seconds or until the windows appear and then remove the style.) Thanks! Alas, these options don´t have the desired effect with Firefox. What has an effect is TileManualPlacement (with FixedPPosition): With TileManualPlacement, I get to place the windows manually when Firefox starts. What I want is MinOverlapPlacement, or MinOverlapPercentPlacement. When I use either, the Firefox windows are placed on top of each other. I was wondering if something is going on that prevents fvwm from noticing for the placement that there are windows already there when Firefox suddenly creates its three because it is creating them too fast or somehow not entirely. Yet getting to do manual placement when TileManualPlacement is used would indicate that fvwm does realise that these windows are being created. The manual placement fvwm falls back to, when TileManualPlacement is used, would indicate that fvwm can not find a smart location for these windows. What could be causing this? Is Firefox somehow claiming the entire screen because it tries to place the windows itself, making fvwm figure there is no good place to put them? Without FixedPPosition, the windows are still being placed on top of each other. I´ll resort to TileManualPlacement for now because it´s easier to place the windows where I want them as they are created than it is to move them once they´re all there. > There's also the option > > bugopts explainwindowplacement on > > Which will print a detailed report to the console when new windows > are placed. You mean the FvwmConsole module? Nothing is printed there when I enable this and place any window.
