On Thu, Mar 7, 2024 at 9:45 AM Chris Siebenmann <cks-f...@cs.toronto.edu> wrote: > > > On Wed, Mar 6, 2024 at 10:45 AM Chris Siebenmann > > <cks-f...@cs.toronto.edu> 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
