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.

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.

Reply via email to