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
hassle.
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
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. 
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