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

Chris Siebenmann <[email protected]> Wed, 06 Mar 2024 12:44:36 -0500
Newsgroups gmane.comp.window-managers.fvwm
Message-ID <[email protected]>
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