Urxvt moves when it only wants to resize its window

[Uli Schlachter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi everyone,

first, I'm not subscribed to this list. Please CC me on replies (if this mail
goes through at all...).

This was originally reported here, even though I also saw older reports which
I do not remember/find right now:

  https://github.com/awesomeWM/awesome/issues/532

The problem is that in the awesomeWM window manager, urxvt moves to the bottom
left when actually nothing should change. This can, for example, be triggered
by running the following in a shell:

  printf '\033]710;xft:monospace:size=10\033\'

The first call will change the font, second, third etc shouldn't change
anything, but will actually make the window move.

A patch for this is attached. I'd like to hear your opinion about this.

An explanation for the patch:

Awesome is a reparenting WM, so we have urxvt's main window (since the code
has a variable with this name, I will call it "parent") and the frame window
that awesome created and reparented 'parent' into (let's call it 'wm_parent').
Awesome has a border around its window and for this it uses X11 window
borders. This means that wm_parent has a non-zero X11 border width. Apparently
this is a feature of X11 which is rarely used these days.

Now when this SMART_RESIZE code runs (see patch), it tries to figure out the
(x, y) position of 'wm_parent' (if 'wm_parent' exists at all). For this, it
gets 'parent''s position relative to 'wm_parent' (x1 and y1 in the code) and
'parent''s position relative to the root window (x, y in the code). The code
then assumes that (x-x1, y-y1) is the position of 'wm_parent'. However, due to
the way that X11 window borders work(*), the calculated value is off by the
border width. Hence, urxvt's window moves due to the following
XMoveResizeWindow().

(*): (x, y) of a window is the position were the border starts and the (0, 0)
pixel of a window is actually at position (x+border, y+border).

The attached patch fixes this by querying the border width of 'wm_parent' and
taking this into account in the calculation of the position. Since (as far as
I know), only awesome has a non-zero border width on its 'wm_parent', this
patch shouldn't have any effect with other WMs. For non-reparenting WM's, this
will end up querying the border width of the root window, which should also be 0
.

An alternative possibility would be to ask the X11 server for (x, y) directly
(this value ends up in (unused_x, unused_y) with my patch). However, I'm not
exactly sure how to make this work for non-reparenting window managers. I
guess the patch wouldn't be simpler than the attached one.

What do you think?

Cheers,
Uli
- -- 
“Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold. Cold.” – Anna
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWLNr/AAoJECLkKOvLj8sGoI4IALIjwy5P5KQ3hJsTKLG/PV6b
8n5rpZ+3pj+H0JCxR59LfF/uG6AjEm2MsjA2Xg6EtReFLpq+FaAQPo11MwiiX7Q/
shTc1MJYsN3fn88TOhvdURc3CMHB5SMcC87A9t1a7rjyB79YcPK5pYqtmAA+fmzD
Uhl0TAn20iAi0bCudN5xkoE4l4EGMp8ulr9NNRwr1gvHghurZ75IBaYOBXyad4To
uY6pZGOT3QH4nFE2bG0a+/vyBAE2CXiJCA6MCgXkSU/R9aWnjYUZmtMpyq4zlcON
EgYDWXLQP+19/Gavq1r/D7WX8dVHA6HKw5HUG+FiLHMw3oCLKU8avPdpByt6xw0=
=C98v
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urxvt.patch
Type: text/x-diff
Size: 1541 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20151025/5ee37041/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: urxvt.patch.sig
Type: application/pgp-signature
Size: 287 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20151025/5ee37041/attachment.sig>