dual-monitor (landscape+portrait) new xterm on other monitor incorrectly resized
Submitted by Zenaan Harkness
Assigned to Olivier Fourdan @olivier
Description
Dear Maintainer,
See most recent email here: https://mail.xfce.org/pipermail/xfce/2017-May/035584.html
See Debian bug report here (same text as below): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861584
See original email here: https://mail.xfce.org/pipermail/xfce/2017-April/035547.html
Two monitors, each 1920x1200 resolution, LHS monitor in landscape RHS in portrait.
So the total "X desktop" space (e.g. on xrandr) is actually: (1920+1200) by 1920 :== 3120 x 1920 but of course some of the "X desktop" area on the left is not usable.
xfwm4 is reasonably capable in its awareness of this situation, but insufficient.
xfwm4 naturally has a built in compensation for this "unavailable area", both resizing, maximising and moving, new windows which are created with parameters "out of limits".
Unfortunately its algorithm for "fixing up the location and size of 'badly' located and sized new X windows" is not correct in the config above, as follows:
When the mouse pointer is on the LHS (e.g. over an xterm from which we launch a new xterm), and a new xterm is launched with geometry targetting the RHS, this works for new xterms which have size which is within the "visible size" of the LHS monitor.
But if the newly created xterm, targetting the RHS monitor, is e.g. taller than the actual physical height of the LHS monitor (and the mouse cursor is within the LHS monitor), then xfwm INCORRECTLY resizes the newly created xterm before displaying it.
Example:
-
have two monitors, LHS in landscape, RHS in portrait
-
make sure mouse cursor is within the bounds of LHS monitor
-
launch from LHS monitor a new xterm, with geometry:
-
height "too large" for LHS monitor, but within RHS monitor "height"
-
width within width of RHS monitor
-
e.g. if using a 6x10 font, and 1920x1200 monitors as above, then:
xterm -geometry 128x150+1920+0
-
-
xfwm incorrectly assesses the new window as "too tall for the current monitor" (rather than "actually, the new window is to be displayed on that second RHS monitor, and it's not too tall for that montor")
-
next, xfwm "reduces" the height of the new window to the maximum for "the on which it is to be displayed", in this case the RHS monitor, which effectively INCREASES the height of the newly created xterm!
-
finally, the new window is displayed (on the 2nd/RHS monitor)
Now, to check what SHOULD happen:
-
same as above, but move the mouse cursor to the RHS monitor, before launching the new xterm
-
xfwm displays and sizes it correctly
The inverse/vice-versa problem also happens (e.g. with mouse cursor on RHS monitor, try to create new xterm "too wide for RHS monitor" but not too wide for LHS monitor, and to be displayed on LHS monitor).
When (again, in above lanscape+portrait monitor config):
- starting xterms from a shell script,
- for both LHS and RHS monitors,
- and at least one RHS term is too tall if it were placed on LHS
- and at least one LHS term is too wide if it were placed on RHS
then there is no way to run this shell script and get the desired xterms layout, which is most definitely a bug.
Finally I note that the wmctrl program could possibly be figured out and used to come in and mop up after xfwm fails to properly lay out the new xterm(s), but that looks quite complicated to me (hey, I haven't used it before :) and certainly this should be unnecessary to do, since I know the exact geometry I want, and I specify the exact, CORRECT geometry when starting my xterms from my script!
One shouldn't have to apply the desired geometry twice, once after the window is created, just to mop up (even if this can be done).
Regards, Zenaan