Re: FVWM: Is Move in fvwm3 supposed to be (current) RandR screen relative?

On Wed, Mar 6, 2024 at 10:51=E2=80=AFAM Jaimos Skriletz
<[email protected]> wrote:
>
> On Wed, Mar 6, 2024 at 10:45=E2=80=AFAM Chris Siebenmann
> <[email protected]> wrote:
> >
> >
> > Is this intended behavior? I can't spot a strong statement either way i=
n
> > 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.