-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any update/feedback on this (especially the patch)?
For what it's worth, it also happens when toggling the scrollbar, using: > printf '\e[?30t' Thanks, Daniel. On 25.10.2015 14:37, Uli Schlachter wrote: > 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 > > > > _______________________________________________ > rxvt-unicode mailing list > [email protected] > http://lists.schmorp.de/mailman/listinfo/rxvt-unicode > -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlaWdJgACgkQfAK/hT/mPgAiGACg+P42HmWCTo+OD2fxsiCADxr5 wPYAnjDNcQl/wbtd7Lcy6Omtal7mVbZ2 =c2oH -----END PGP SIGNATURE----- _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
