>> >> -#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?
>>
>
> No.
Thanks. Did you ever get an assertion failure for the original frame?
If not, then we should try to understand why not. Please with pristine
master replace the initial assignment of 'frame-size-history' in frame.c
from
frame_size_history = Qnil;
to
frame_size_history = Fcons (make_fixnum (100), Qnil);
start Emacs -Q and tell me the contents of the *frame-size-history*
buffer. The idea is that if the initial frame gets it right, what can
we do to make subsequent C-x 5 2 calls get it right.
>> find out whether 400x340 is some built-in size used by the WM or GTK
>> or something Emacs itself has used before.
>>
>
> Since this size crops up with emacs -Q, it doesn't seem to be related to
> something Emacs has used before. I did also grep through my ~/.emacs.d
> directory, but I couldn't find anything relevant there.
Sorry. I meant something in the history of the frame creation
'frame-size-history' doesn't catch like the initial assignments in
make_frame combined with the values of FRAME_COLUMN_WIDTH and
FRAME_LINE_HEIGHT
FRAME_COLS (f) = FRAME_TOTAL_COLS (f) = rw->total_cols = 80;
FRAME_TEXT_WIDTH (f) = FRAME_PIXEL_WIDTH (f) = rw->pixel_width
= 80 * FRAME_COLUMN_WIDTH (f);
FRAME_LINES (f) = FRAME_TOTAL_LINES (f) = 25;
FRAME_TEXT_HEIGHT (f) = FRAME_PIXEL_HEIGHT (f) = 25 * FRAME_LINE_HEIGHT (f);
or what gui_figure_window_size concocts with the size hints.
> (4) Look for other causes. Could scaling be involved?
>
>
> My GNOME desktop is scaled by 200%, so it could be.
Can you try not using any scaling experimentally? Jan always complained
that GTK does not handle scaling orderly (that is, in our sense).
>> (5) Finally, the most important: Can other users observe the same or
>> similar behavior as Reuben?
>>
>
> Several bugs were already reported of similar behaviour, no? Or maybe you
> meant something more specific.
I meant in the light of what I've written here. IIUC nobody so far has
noticed the two idempotent xg_frame_set_char_size calls and how the
second one sometimes magically fixes things. It would be interesting to
find out whether such "fixes" happen all the time without being noticed.
Also most people have identified natural allocation distribution as a
possible culprit and not as a potential victim. And if the WM is the
culprit, why does the same WM handle Lucid frames or those without
toolkit correctly? Maybe the WM is a racist, maybe we are.
Thanks, martin
