>> -#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
>> +#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
>>
>
> OK, so I applied this patch and ran `emacs -Q`, then did C-x 5 2 and got
> the usual small window and error:
>
> (emacs:3159980): Gtk-CRITICAL **: 13:05:49.056:
> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
Do you get an assertion failure already before the C-x 5 2?
>> Now set
>>
>> (setq default-frame-alist '((menu-bar-lines . 0)))
>>
>> and do C-x 5 2. How does that behave?
>>
>
> That opens a small window with no error message.
From what you've tested till now I can conclude the following.
Your Emacs requests a frame size of 1328x1260 pixels and for some
inexplicable reason your Emacs _always_ gets a ConfigureNotify
notification that tells it that the frame has been shrunk to 400x340
pixels. Below, the values marked with XS are the requested values and
show up as:
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
...
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
The equivalent sequence on my system is
xg_frame_set_char_size, invisible, PS=752x792, XS=752x792, DS=752x792
...
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
Now two things may happen on your system. In one scenario you get a
second ConfigureNotify event, this time with the expected size:
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=400x322
Emacs complies and there are no further issues. This is the scenario
with commit 24161683102 reverted.
Note: The second ConfigureNotify event in this scenario seems to be a
result of Emacs issuing two apparently identical requests as
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
...
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
with maybe different menu bar sizes. We have yet to find out what
causes the second request.
In the other scenario Emacs complies with the sizes received in the
ConfigureNotify event, re-issues a new resize request with the small
sizes and the next ConfigureNotify event does not cause any change.
xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340
...
ConfigureNotify, PS=1328x1260, XS=400x340, DS=400x340
The small frame size stays. This is the scenario with current master.
There is no previous second request from the side of Emacs.
One thing that we'd have to verify yet is whether the
gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
can happen only when Emacs issues the
xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340
request (which I'd expect) or already when we get the ConfigureNotify
event (which I doubt). In either case, I think that the assertion
failure is only a consequence of getting an unreasonable size and not
the cause of it.
Where could we go from here?
(1) Try to find out why we always get a
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
after requesting the larger size. For this purpose we would have to
find out whether 400x340 is some built-in size used by the WM or GTK
or something Emacs itself has used before.
(2) Find out why Emacs in one scenario issues a second resize request
and doesn't do that with the reverted commit. Maybe Po Lu can tell. I
also suppose that the missing second resize request is also the reason
why the menubar-less frame always shrinks. Maybe we should _always_
fake such a request - idempotent resize requests should never harm.
(3) Do not flush events. Could
gdk_flush ();
#ifndef HAVE_PGTK
x_wait_for_event (f, ConfigureNotify);
#endif
flush a ConfigureNotify event to which we should have reacted?
(4) Look for other causes. Could scaling be involved? Do we calculate
size hints correctly - mutter is very selective about these. Should we
delay setting the frame's visibility?
(5) Finally, the most important: Can other users observe the same or
similar behavior as Reuben?
martin
