bug#65217: 29.1; set-frame-size gets confused and drops calls

[Eli Zaretskii]

> Date: Fri, 18 Aug 2023 10:25:27 +0200
> Cc: 65217@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
> The first thing xg_frame_set_char_size (the function responsible for
> dispatching the 'set-frame-size' call to GTK) does is to call
> gtk_window_get_size to get the "current size" of the window showing the
> frame.  The doc of that function says that
> 
>   * Depending on the windowing system and the window manager constraints,
>   * the size returned by this function may not match the size set using
>   * gtk_window_resize(); additionally, since gtk_window_resize() may be
>   * implemented as an asynchronous operation, GTK+ cannot guarantee in any
>   * way that this code:
>   *
>   * |[<!-- language="C" -->
>   *   // width and height are set elsewhere
>   *   gtk_window_resize (window, width, height);
>   *
>   *   int new_width, new_height;
>   *   gtk_window_get_size (window, &new_width, &new_height);
>   * ]|
>   *
>   * will result in `new_width` and `new_height` matching `width` and
>   * `height`, respectively.
> 
> where gtk_window_resize (window, width, height) corresponds to our
> (set-frame-size my/frame 10 10) and the gwidth and gheight used in the
> earlier mentioned
> 
>        if (outer_width != gwidth || outer_height != gheight)
> 
> check are the new_width and new_height values returned by
> gtk_window_get_size.  So since we've been warned by the GTK people, the
> attached patch which removes that conditional seems in order.

Po Lu, do you agree with the patch?  If you do, I'll install it on
master.

> Note that all other uses of gwidth and gheight remain in place and may
> cause the above mentioned problems so maybe we should warn about this in
> PROBLEMS.

Please suggest the text for PROBLEMS, I think this is a good idea.

Thanks.