bug#46827: Broken initial size of GTK3 frame

[Eli Zaretskii]

> Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 2 Mar 2021 17:07:16 +0100
> 
>  > What's wrong with this place?
> 
> Actually, it's not needed.  I just have to call do_pending_window_change
> _after_ updating the tool bar as in the attached patch.

Thanks, but is there any reason to remove the call before updating the
tool bar?  You see, I believe one of the reasons for the need to
clear_garbaged_frames is that call you suggest to remove.  Why not
leave it there, and _add_ one more call after prepare_menu_bars (and
perhaps condition it on the same condition as prepare_menu_bars)?

>  > But please note that after calling
>  > do_pending_window_change you need to perform the "maybe the selected
>  > window changed" dance we do after other similar calls.
> 
> I suppose the
> 
>        do_pending_window_change could change the selected_window due to
>        frame resizing which makes the selected window too small.
> 
> is some sort of cargo cult now.  While frame resizing can make the
> selected window small, it will neither remove nor change it.

Never-ever?

>  > Otherwise, I'm okay with this change, but only on master.  Emacs 27.2
>  > will have to make do with what we have now.
> 
> Don't worry.  Even on master we could condition it on GTK3.  I'd just
> want to find out why it works around the problem in the first place.

I suspect that the code which calculates the dimensions of the tool
bar causes this.

> And I have a second, similar GTK3-only frame resizing problem with a
> similar effect that, however, becomes virulent only after resizing a
> frame manually with the mouse.

Fun.