unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Reuben Thomas <rrt@sc3d.org>
Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>,
	72986@debbugs.gnu.org
Subject: bug#72986: Disabling menu-bar-mode changes size of new frames
Date: Sun, 8 Sep 2024 10:42:41 +0200	[thread overview]
Message-ID: <ef1023a7-5d64-41c9-9924-c89b2b4746f6@gmx.at> (raw)
In-Reply-To: <CAOnWdoj7sFPfvrkkKadhXWaFYev+E9OOKBN7vsm_-tV=x-N5WA@mail.gmail.com>

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





  reply	other threads:[~2024-09-08  8:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02 18:48 bug#72986: Disabling menu-bar-mode changes size of new frames Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 12:07 ` Eli Zaretskii
2024-09-03 12:09   ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 15:52   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 15:59     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 17:03       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 17:29         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 17:42           ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04  8:01           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04 11:23             ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04 12:12               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04 13:05                 ` Robert Pluim
2024-09-04 17:11               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04 22:45                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05  7:49                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 19:31                     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06  7:54                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06  8:11                         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06  9:50                           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06 12:20                             ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06 14:16                               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-06 15:14                                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-07  8:37                                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-07 12:07                                     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08  8:42                                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-09-08 11:38                                         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 14:21                                           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 15:20                                             ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 16:54                                               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 17:32                                                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09  8:58                                                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09  9:49                                                     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09 12:33                                                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09 13:59                                                         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09 16:52                                                           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-09 17:52                                                             ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-10  9:31                                                               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-10 17:00                                                                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-10 17:16                                                                   ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-12 16:24                                                                     ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-14 14:43                                                                       ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-15 12:40                                                                         ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-16  8:46                                                                           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-03 17:44         ` Eli Zaretskii
2024-09-03 18:34           ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04  8:05           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef1023a7-5d64-41c9-9924-c89b2b4746f6@gmx.at \
    --to=bug-gnu-emacs@gnu.org \
    --cc=72986@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=rrt@sc3d.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).