GNU bug report logs - #72986
Disabling menu-bar-mode changes size of new frames

Previous Next

Full log

Message #86 received at 72986 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>,
 72986 <at> debbugs.gnu.org
Subject: Re: bug#72986: Disabling menu-bar-mode changes size of new frames
Date: Sun, 8 Sep 2024 10:42:41 +0200

>> -#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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.