On Fri, Aug 24, 2018 at 10:41:45PM +0200, hw wrote: > Dominik Vogt <dominik.v...@gmx.de> 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.
Are you sure that the styles match? If windows would be created without a name first, the style does not match, and firefox could do with them what it wants. > 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. You mean as a command or as a style? > 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. No, in the output of the X server, wherever that goes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
