Forcing (most) apps to ignore part of current page

My most recent fvwm puzzler:

I’ve got a 1-column pager running along the far right of the page. It’s set to StaysOnTop,
and sometimes a new window will be partially obscured by it, which presents a minor

Given that the pager is X pixels wide, is there a configuration directive that will allow
allow me to declare the rightmost ($[vp.width] - X) pixels of the viewport to be available
only to FvwmPager?

If there is, what portion of the fvwm manual page is relevant?

Thank you!

See the EWMHBaseStruts command.

– Thomas Adam

Interesting; I applied the EwmhBaseStruts command as suggested, and it seems to be (in general) working properly. However, with the following directive in place, Firefox windows will not appear on the screen – I get the “Restore Previous Session or Create New Session” dialog, but that’s it. If I comment it out, log out of X, and then log back in, Firefox windows appear as expected.

 EwmhBaseStruts 0 $[vp.width] 0 $[vp.height]

Has anyone noticed this sort of behavior before, and if so, was a fix found? Any information would be appreciated!

What Style line(s) do you have for firefox? And, better yet, put your config file somewhere for inspection.

– Thomas Adam

No styles set explicitly for Firefox.


Thank you!

I’m assuming this bug is related to the fact that PPosition hints are involved. As a complete kludge (until I fix it and send a patch in), does:

PipeRead `EwmhBaseStruts 0 $(( $[vp.width] - 1)) 0 $(( $[vp.height] - 1))`

In place of your current call to EwmhBaseStruts solve your problem? It ought to.

– Thomas Adam

Doesn’t that basically tell fvwm to: “Reserve space 0 pixels from left, the width of the virtual page from right, 0 pixels from top, and the height of virtual page from bottom”. In short: “reserve the whole desk”? (ie. it’s doing just what it’s asked for). Also, isn’t the profile pick dialog a modal window?

Kind of – but it affects more than just placement, and coerces many applications.

No it isn’t, but what makes you think it would make a difference?

– Thomas Adam

It does indeed. Many thanks.

Well, I’m not really familiar with the inner workings of them, but I’ve always thought that modal windows get special treatment from wm. I was thinking something like: fvwm moves the main ffox window out of way because of the struts definition, but the modal window is kinda like a child window of ffox itself, and would’ve got special treatment from wm to not get spawned outside of strutboundaries. But because it’s not a modal, then, well, my theory got trashed. :wink:

Well, the problem here is that not all transient windows are modal. Modal implies just that – it has a specific and forceful means of coercing the user to do something. Motif applications in particular did this – the ModalityIsEvil BugOpts workaround in FVWM also attempts to get the WM to ignore Modal hints on windows.

Transient windows are just windows which are short-lived but might imply some form of “modalness” about them; the difference more is that unlike modal windows they don’t force the parent application to be unresponsive until the child window has closed.

No, this is way off beam.

– Thomas Adam