Re: FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?
On Thu, Mar 7, 2024 at 9:45 AM Chris Siebenmann wrote: > > > On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann > > wrote: > > > Is this intended behavior? I can't spot a strong statement either way in > > > the current documentation for Move, although some of the wording sounds > > > a bit odd if explicit Move positions are supposed to be screen relative. > > > > Move honors EWMHBaseStruts, which even if they are zero, are now set > > per monitor. Due to this some computations don't work as you would > > expect, since fvwm will adjust the window location to be inside the > > working area of the current monitor. Does telling Move to ignore the > > base strust fix your issue. I.e. add ewmhiwa to the end of each of > > your Move commands. > > > > Move 3370p -0p ewmhiwa > > This does indeed work in my testing. > > In general this seems like a surprising change, since historically fvwm > has considered Move to be absolute, not per-monitor (well, current > monitor). It may make sense for people who explicitly use an EWMH area, > but for people who don't (and the area is implicitly the entire > monitor), maybe something else should be done. > Fvwm has honored base struts with Move this way for a long time and the ewmhiwa option is not new, so Move wasn't considered absolute. The difference is with Xinemera these struts were in the bounding box of all monitors, so it probably wasn't noticed unless you moved a window partly outside of this bounding box, then fvwm would have ensured the window was fully inside this bounding box unless ewmhiwa option was added. The RandR change now gives per-monitor support and a lot more control, and this default is still useful to ensure Move puts windows inside a single monitor unless ewmhiwa is used. The issue (which isn't an easy fix) is that fvwm cannot determine which monitor to use in some cases, and will fallback to the current monitor (the one with the mouse pointer) if no monitor is specified. I do agree it would be nice if fvwm could better determine which monitor to use when doing bounding box computations to ensure windows are fully shown inside a single monitor, but I still think using the bounding boxes with Move and other operations to ensure windows are put inside a single monitor or working area is useful. Currently the work arounds are to either tell move to ignore the bounding box or specify which monitor you want it to use. jaimos
Re: FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?
> On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann > wrote: > > Is this intended behavior? I can't spot a strong statement either way in > > the current documentation for Move, although some of the wording sounds > > a bit odd if explicit Move positions are supposed to be screen relative. > > Move honors EWMHBaseStruts, which even if they are zero, are now set > per monitor. Due to this some computations don't work as you would > expect, since fvwm will adjust the window location to be inside the > working area of the current monitor. Does telling Move to ignore the > base strust fix your issue. I.e. add ewmhiwa to the end of each of > your Move commands. > > Move 3370p -0p ewmhiwa This does indeed work in my testing. In general this seems like a surprising change, since historically fvwm has considered Move to be absolute, not per-monitor (well, current monitor). It may make sense for people who explicitly use an EWMH area, but for people who don't (and the area is implicitly the entire monitor), maybe something else should be done. (I know I have other Move-using scripting that's now going to need changes so it's not monitor-relative.) - cks
Re: FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?
On Wed, Mar 6, 2024 at 10:51 AM Jaimos Skriletz wrote: > > On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann > wrote: > > > > > > Is this intended behavior? I can't spot a strong statement either way in > > the current documentation for Move, although some of the wording sounds > > a bit odd if explicit Move positions are supposed to be screen relative. > > Move honors EWMHBaseStruts, which even if they are zero, are now set > per monitor. Due to this some computations don't work as you would > expect, since fvwm will adjust the window location to be inside the > working area of the current monitor. Does telling Move to ignore the > base strust fix your issue. I.e. add ewmhiwa to the end of each of > your Move commands. > > Move 3370p -0p ewmhiwa > > The other option is as you stated, make your move commands relative to > a specific monitor (instead of the current one) for when base strut > calculations are used. > > jaimos I forgot to send my response to the list.
FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?
I've recently written an fvwm3 function to move and place my Emacs mail reading windows: DestroyFunc MHEEmacsPosition AddToFunc MHEEmacsPosition + I Next ("+inbox", "Emacs") Iconify False + I Next ("+inbox", "Emacs") Resize 80c 46c + I Next ("+inbox", "Emacs") Move 3840p -0p + I Next ("+inbox", "Emacs") Iconify True + I Next ("+inbox", "Emacs") Move 5070p 86p + I Next ("Speedbar", "Emacs") Iconify False + I Next ("Speedbar", "Emacs") Resize 26c 47c + I Next ("Speedbar", "Emacs") Move 3370p -0p + I Next ("Speedbar", "Emacs") Iconify True + I Next ("Speedbar", "Emacs") Move 5159p 86p I have two 4K HiDPI displays side by side, each 3840x2160, and this is supposed to place the icons and one of the Emacs windows on the right screen. If I invoke this function from my menus with the mouse pointer in the left screen, it works as I expect, but if I invoke it with the pointer in the right screen, the icons are placed off-screen to the right. So it seems that 'Move' is being interpreted as screen-relative, not total display (or page) relative. Is this intended behavior? I can't spot a strong statement either way in the current documentation for Move, although some of the wording sounds a bit odd if explicit Move positions are supposed to be screen relative. My current workaround is 'Move Screen $[monitor.0] ...', but that might not be the best answer (even if Move is screen relative). - cks