bug#62135: xterm.c: (x_set_offset)

[Madhu <enometh@meer.net>]

* Po Lu via  <87y1o2ba50.fsf@yahoo.com> :
Wrote on Sun, 12 Mar 2023 17:18:35 +0800:

> Madhu <enometh@meer.net> writes:
>
>> While investingating some persistent placements at 0x0 by some wm, I was
>> looking at x-set-offset, (which gets called via x_make_frame_visible).
>>
>> In the code below there is a comment that documents the role of the
>> change_gravity argument.  When called from x_make_frame_visible the
>> parameter is set to 0, so as not to do anything. However lines
>> 22713-22720 perform an unconditional move window, which happens in
>> this code path even before the XWindow the mapped.
>>
>> 1) Shouldn't these lines be protected by a "if (change_gravity != 0) {
>> ... }" conditional?
>>
>> My surmise is that most wms ignore the call to XMoveWindow because it is
>> unmapped but at least wayfire (on Xwayland) persistently seems to
>> position it at 0, 0 as the code calls it.
>
> `change_gravity' means the function should update f->top_pos and
> f->left_pos, then reset the window gravity, as well as move the window
> to f->top_pos and f->left_pos.

certainly, when called from set-frame-position.

> `change_gravity' < 0 means to leave f->top_pos and f->left_pos intact.
>
> However, at that point, the window's configuration is not guaranteed to
> have its origin at f->top_pos and f->left_pos, so the window must still
> be moved over.

certainly, when change_gravity < 0.

But I don't think this statement is true when mapping an unmapped window
when change_gravity == 0.  does the code in x_set_offset alter top and
left positions if change_gravity == 0?  unless the function changes the
positions a call to XMoveWindow should not be necessary.

if an existing frame has been made invisible, the x and y size hints
would have been set along with USPosition and the I presume the wm
(minus bugs) would use them if needed when mapping the unmapped window.

likewise if a new frame is being mapped with top, left, and
user-position set (I haven't double-checked this again) the wm hints
would be set, and an explicit move would be unnecessary when mapping the
new window.

In both these cases change_gravity is set to 0, and there should be no
need to move the window at this step.

> Thus, the code is correct.  The comment above the
> function is somewhat misleading but still correct.