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