> 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.
(I know I have other Move-using scripting that's now going to need
changes so it's not monitor-relative.)
- cks
