Unmaximizing a window on a different desk moves but won't map the window.

[somiaj]

First there is an inconsistency between Maximize True and Maximize False on a window that is not on the current desktop of a monitor. Maximize True will maximize the window but leave it on the same desk/page it was on. While Maximize False will restore the window's size, then move it to the current desk/page of the monitor it is on.

Second, when moving the restored window to the current monitor, the window is not mapped and cannot be seen. Switching to a different desk and back will remap the window, showing it again.

I think the behavior between maximize and unmaximize needs to be consistent, and prefer that they do not change the desk/page of a window. It could be scripts/modules want to modify the state of windows on different desks in the background. Moving the window to the current desk/page can always be done in a second command if desired.

[ThomasAdam]

This is something which had come up a lot on the fvwm mailing list.

I think not moving a window coming out of a maximized state to the current monitor makes sense.

What should happen if a maximized window moves monitors -- should the unmaximized window use that new monitor? At the moment it does not -- and instead, the original window geometry is restored, which could include changing the monitor.

I think I'm OK with that -- someone can write a function to correct that situation.

[somiaj]

Yea, the per-monitor mode makes things a little more complicated when switching monitors to ensure mappings happen properly and sometimes trying to guess where the user would want the window.

Though I agree, probably best to leave things where they are when possible for cases users want to modify windows in the background (such as what kept happening with the pager). If users need to move the window to the current desk of a monitor, as mentioned, they can write a custom function that would do this for their use case.

[ThomasAdam]

Yes indeed. Will merge this change.