bug#46827: Broken initial size of GTK3 frame

[martin rudalics]

> 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)?

We can obviously do that (see attached patch).  But is there any reason
we cannot run the

  do_pending_window_change (true);
  clear_garbaged_frames ();

_after_ the

      prepare_menu_bars ();
      do_pending_window_change (true);

block?

In either case, the more I look into this, the more things confuse me.
For example, why does

          if (!must_finish)
            {
              do_pending_window_change (true);
              /* If selected_window changed, redisplay again.  */
              if (WINDOWP (selected_window)
                  && (w = XWINDOW (selected_window)) != sw)
                goto retry;

not check for windows_or_buffers_changed too just as we do after the
third do_pending_window_change call?  But then I don't understand why we
check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
set that IIUC but it does garbage the frame - why don't we check that in
redisplay_internal?

>> While frame resizing can make the
>> selected window small, it will neither remove nor change it.
>
> Never-ever?

Never-ever.  Fdelete_window_internal, Fdelete_other_windows_internal and
Fset_window_configuration are the only functions allowed to delete
windows.  run_window_change_functions could delete the selected window
so we probably should do the w == sw check after that now.

martin

xdisp.c.diff
Description: Text Data