bug#72986: Disabling menu-bar-mode changes size of new frames

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]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Reproduction with Emacs 29.3 (also with git master HEAD, see below).

Run: emacs -Q
C-x 5 2 ; window opens the same size as the initial window
M-x menu-bar-mode RET ; disable menu-bar-mode
C-x 52 ; window opens much smaller than initial window

With master HEAD (commit 92ea393a16e), the situation is slightly different:

Run: emacs -Q
C-x 52 ; window opens much smaller than initial window

When the new windows are opening at a small size, changing
default-frame-alist has no effect. When the new windows are opening at the
same size as the initial window (with Emacs 29.3, as above), then changing
default-frame-alist works as expected.

I'm running on Ubuntu 24.04, under GNOME 46 with X11. I don't have any
Emacs X resources set.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2321 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[Eli Zaretskii]

> Date: Mon, 2 Sep 2024 19:48:57 +0100
> From:  Reuben Thomas via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Reproduction with Emacs 29.3 (also with git master HEAD, see below).
> 
> Run: emacs -Q
> C-x 5 2 ; window opens the same size as the initial window
> M-x menu-bar-mode RET ; disable menu-bar-mode
> C-x 52 ; window opens much smaller than initial window
> 
> With master HEAD (commit 92ea393a16e), the situation is slightly different:
> 
> Run: emacs -Q
> C-x 52 ; window opens much smaller than initial window

I cannot reproduce this, but I'm not on X.  Here on MS-Windows,
disabling menu-bar-mode makes the frames one line smaller, and
thereafter "C-x 5 2" creates frames whose dimensions are exactly
identical to the existing frames.  As expected.

I see the above both in Emacs 29, on the current emacs-30 release
branch, and on master.

> I'm running on Ubuntu 24.04, under GNOME 46 with X11. I don't have any Emacs X resources set.

You didn't say which toolkit did you build with.  It might be
important.

Adding Martin and Po Lu in the hope that they will have comments
and/or suggestions.

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]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

On Tue, 3 Sept 2024 at 13:07, Eli Zaretskii <eliz@gnu.org> wrote:

>
> You didn't say which toolkit did you build with.  It might be
> important.
>

gtk-3 in both cases.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 976 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> Reproduction with Emacs 29.3 (also with git master HEAD, see below).
 >>
 >> Run: emacs -Q
 >> C-x 5 2 ; window opens the same size as the initial window
 >> M-x menu-bar-mode RET ; disable menu-bar-mode

Here with a GTK-3 build on XFCE disabling menu-bar-mode makes both
frames smaller by the menu bar height.  Does this happen on your system?

 >> C-x 52 ; window opens much smaller than initial window
 >>
 >> With master HEAD (commit 92ea393a16e), the situation is slightly different:
 >>
 >> Run: emacs -Q
 >> C-x 52 ; window opens much smaller than initial window

In all these cases after every single step please evaluate

(frame-geometry)

and post the results here.  The window manager is mutter, I suppose?

Thanks, martin

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]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

On Tue, 3 Sept 2024 at 16:52, martin rudalics <rudalics@gmx.at> wrote:

>  >> Reproduction with Emacs 29.3 (also with git master HEAD, see below).
>  >>
>  >> Run: emacs -Q
>  >> C-x 5 2 ; window opens the same size as the initial window
>  >> M-x menu-bar-mode RET ; disable menu-bar-mode
>
> Here with a GTK-3 build on XFCE disabling menu-bar-mode makes both
> frames smaller by the menu bar height.  Does this happen on your system?
>

Yes it does.

 >> C-x 52 ; window opens much smaller than initial window
>  >>
>  >> With master HEAD (commit 92ea393a16e), the situation is slightly
> different:
>  >>
>  >> Run: emacs -Q
>  >> C-x 52 ; window opens much smaller than initial window
>
> In all these cases after every single step please evaluate
>
> (frame-geometry)
>
> and post the results here.


Sure thing:

Emacs 29:

emacs -Q
(frame-geometry): ((outer-position 1127 . 81) (outer-size 1384 . 1504)
(external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 .
46) (menu-bar-external . t) (menu-bar-size 1328 . 50) (tab-bar-size 0 . 0)
(tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1328 . 82)
(internal-border-width . 0))
C-x 5 2
menu-bar-mode RET
(frame-geometry): ((outer-position 1127 . 81) (outer-size 1384 . 1454)
(external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 .
46) (menu-bar-external . t) (menu-bar-size 0 . 0) (tab-bar-size 0 . 0)
(tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1328 . 82)
(internal-border-width . 0))
C-x 5 2
(frame-geometry): ((outer-position 28 . 90) (outer-size 456 . 570)
(external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 .
46) (menu-bar-external . t) (menu-bar-size 0 . 0) (tab-bar-size 0 . 0)
(tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 400 . 82)
(internal-border-width . 0))

Emacs git master (commit 92ea393a16e):
emacs -Q
(frame-geometry): ((outer-position 28 . 90) (outer-size 1384 . 1504)
(external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 .
46) (menu-bar-external . t) (menu-bar-size 1328 . 50) (tab-bar-size 0 . 0)
(tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 1328 . 82)
(internal-border-width . 0))
C-x 5 2
(frame-geometry): ((outer-position 108 . 170) (outer-size 456 . 620)
(external-border-size 28 . 34) (outer-border-width . 0) (title-bar-size 0 .
46) (menu-bar-external . t) (menu-bar-size 400 . 50) (tab-bar-size 0 . 0)
(tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 400 . 82)
(internal-border-width . 0))

The window manager is mutter, I suppose?
>

Indeed, yes.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 5657 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Sure thing:

Thanks.  The geometry values are consistent with what you described.
This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559.  When
you run Emacs from a console or under gdb can you observe whether it
triggers a

gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

which typically means that the menubar cannot be accommodated.

The one really notable difference to the above bugs is that the 29
version makes a shrunk frame only after you've removed the menubar while
master makes a shrunk frame immediately.  Are the GTK versions of the
Emacs 29 build and the master build the same?

 > The window manager is mutter, I suppose?
 >>
 >
 > Indeed, yes.

mutter doesn't like us.  Just to make sure one thing: Would setting
'frame-resize-pixelwise' to t change anything?

Otherwise I would try to build Emacs with gtk2, lucid or motif.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Tue, 3 Sept 2024 at 18:03, martin rudalics <rudalics@gmx.at> wrote:

>  > Sure thing:
>
> Thanks.  The geometry values are consistent with what you described.
> This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559.  When
> you run Emacs from a console or under gdb can you observe whether it
> triggers a
>
> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>

Yes, both with Emacs 29 and git master produce this message when
menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes
(the normal sized window, and the strangely small one).

The one really notable difference to the above bugs is that the 29
> version makes a shrunk frame only after you've removed the menubar while
> master makes a shrunk frame immediately.  Are the GTK versions of the
> Emacs 29 build and the master build the same?
>

Yes, they are identical: gtk 3.24.41, Ubuntu build.

Just to make sure one thing: Would setting
> 'frame-resize-pixelwise' to t change anything?
>

So, I did (setq frame-resize-pixelwise t), then disabled menu-bar-mode (in
Emacs 29), then C-x 5 2 (in both Emacs 29 & git master), and the new window
was small, just as before. It seems therefore to make no difference.

Otherwise I would try to build Emacs with gtk2, lucid or motif.


I tried building Emacs git master with gtk2, and it doesn't fix the
problem: the second window opened is slightly smaller than before (i.e.
very small indeed).

Building with lucid does fix the problem (both with menu-bar-mode enabled,
and disabled).

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3239 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On Tue, 3 Sept 2024 at 18:29, Reuben Thomas <rrt@sc3d.org> wrote:

>
> Otherwise I would try to build Emacs with gtk2, lucid or motif.
>
>
>
I can confirm that building with no toolkit (as recommended in the issues
you mentioned) also fixes the problem.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1059 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 >> Thanks.  The geometry values are consistent with what you described.
 >> This seems to be Bug#67654 and Bug#68463 and possibly Bug#65559.  When
 >> you run Emacs from a console or under gdb can you observe whether it
 >> triggers a
 >>
 >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
 >>
 >
 > Yes, both with Emacs 29 and git master produce this message when
 > menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes
 > (the normal sized window, and the strangely small one).

But you can't see this message when building with gtk-2 I presume.

 > The one really notable difference to the above bugs is that the 29
 >> version makes a shrunk frame only after you've removed the menubar while
 >> master makes a shrunk frame immediately.  Are the GTK versions of the
 >> Emacs 29 build and the master build the same?
 >>
 >
 > Yes, they are identical: gtk 3.24.41, Ubuntu build.

This strongly hints that there was an Emacs change affecting gtk-2 _and_
gtk-3 builds in between 29 and master.  I could imagine that commit

e087c89b1e243bbd941a4a50b4bf99613e13d016

is involved but if you could try to bisect, it would be of great help.

 > Just to make sure one thing: Would setting
 >> 'frame-resize-pixelwise' to t change anything?
 >>
 >
 > So, I did (setq frame-resize-pixelwise t), then disabled menu-bar-mode (in
 > Emacs 29), then C-x 5 2 (in both Emacs 29 & git master), and the new window
 > was small, just as before. It seems therefore to make no difference.

Which should eliminate the possibility that our size hints are
responsible.  IIRC mutter is very severe when size hints are not set up
correctly.

 > Otherwise I would try to build Emacs with gtk2, lucid or motif.
 >
 >
 > I tried building Emacs git master with gtk2, and it doesn't fix the
 > problem: the second window opened is slightly smaller than before (i.e.
 > very small indeed).

This would eliminate earlier conjectures that changes from one gtk-3
version to another would be responsible.  And it would exclude
emacsgtkfixed.c as possible culprit.

 > Building with lucid does fix the problem (both with menu-bar-mode enabled,
 > and disabled).

I suppose that all these problems happen when requests travel from GTK
to mutter and back.  Basically, mutter is not obliged to fulfill any
size or position request for any top-level (non-child frame).  BTW,
could you try adding a (user-size . t) member to 'default-frame-alist'?
And could you try doing that from an 'early-init.el' file?

martin

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]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

On Wed, 4 Sept 2024 at 09:02, martin rudalics <rudalics@gmx.at> wrote:

>  >>
>  >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>  >>
>  >
>  > Yes, both with Emacs 29 and git master produce this message when
>  > menu-bar-mode is non-nil, and the menu bar is drawn, in both window
> sizes
>  > (the normal sized window, and the strangely small one).
>
> But you can't see this message when building with gtk-2 I presume.
>

That's correct, no message with gtk-2.

This strongly hints that there was an Emacs change affecting gtk-2 _and_
> gtk-3 builds in between 29 and master.  I could imagine that commit
>
> e087c89b1e243bbd941a4a50b4bf99613e13d016
>
> is involved but if you could try to bisect, it would be of great help.
>

Just to check, you're suggesting that I bisect from emacs-29.3 (I use that
tag because it's what the version of 29 I'm using is built from) to master
HEAD, to find at which commit C-x 5 2 opens a small window immediately
(without disabling menu-bar-mode)?

BTW, could you try adding a (user-size . t) member to 'default-frame-alist'?
> And could you try doing that from an 'early-init.el' file?
>

This made no difference. I added just:

(add-to-list 'default-frame-alist '(user-size . t))

to ~/.config/emacs/early-init.el

Then I ran each Emacs with just "emacs", confirmed that default-frame-alist
was set, then disabled menu-bar-mode (Emacs 29 only), then C-x 5 2. In each
case a small window was opened as before.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3466 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Reuben Thomas <rrt@sc3d.org> writes:

> On Wed, 4 Sept 2024 at 09:02, martin rudalics <rudalics@gmx.at> wrote:
>
>   >>
>   >> gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
>   >>
>   >
>   > Yes, both with Emacs 29 and git master produce this message when
>   > menu-bar-mode is non-nil, and the menu bar is drawn, in both window sizes
>   > (the normal sized window, and the strangely small one).
>
>  But you can't see this message when building with gtk-2 I presume.
>
> That's correct, no message with gtk-2.
>
>  This strongly hints that there was an Emacs change affecting gtk-2 _and_
>  gtk-3 builds in between 29 and master.  I could imagine that commit
>
>  e087c89b1e243bbd941a4a50b4bf99613e13d016
>
>  is involved but if you could try to bisect, it would be of great help.
>
> Just to check, you're suggesting that I bisect from emacs-29.3 (I use
> that tag because it's what the version of 29 I'm using is built from)
> to master HEAD, to find at which commit C-x 5 2 opens a small window
> immediately (without disabling menu-bar-mode)?

If it is this bug that you are trying to isolate, we have already heard
reports of its being reproducible all the way to Emacs 26.1, and
concluded that it is a product of a change in the Mutter window manager.

Too bad I'm only personally interested in the no toolkit and Motif
builds and cannot set aside the time to investigate these GTK issues at
this time.

bug#72986: Disabling menu-bar-mode changes size of new frames

[Robert Pluim]

>>>>> On Wed, 04 Sep 2024 20:12:28 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:

    Po Lu> If it is this bug that you are trying to isolate, we have already heard
    Po Lu> reports of its being reproducible all the way to Emacs 26.1, and
    Po Lu> concluded that it is a product of a change in the Mutter window manager.

As a reference point: I donʼt see this issue here with mutter 43.8

Robert
-- 

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Just to check, you're suggesting that I bisect from emacs-29.3 (I use that
 > tag because it's what the version of 29 I'm using is built from) to master
 > HEAD, to find at which commit C-x 5 2 opens a small window immediately
 > (without disabling menu-bar-mode)?

That's the idea, yes.

 > This made no difference. I added just:
 >
 > (add-to-list 'default-frame-alist '(user-size . t))
 >
 > to ~/.config/emacs/early-init.el
 >
 > Then I ran each Emacs with just "emacs", confirmed that default-frame-alist
 > was set, then disabled menu-bar-mode (Emacs 29 only), then C-x 5 2. In each
 > case a small window was opened as before.

I had no hope that this would help.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Wed, 4 Sept 2024 at 18:11, martin rudalics <rudalics@gmx.at> wrote:

>  > Just to check, you're suggesting that I bisect from emacs-29.3 (I use
> that
>  > tag because it's what the version of 29 I'm using is built from) to
> master
>  > HEAD, to find at which commit C-x 5 2 opens a small window immediately
>  > (without disabling menu-bar-mode)?
>
> That's the idea, yes.
>

Thanks for confirming.

My bisection suggests the problematic commit is
241616831024c9c9fe2b2378b611db0a560b9675

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1353 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > My bisection suggests the problematic commit is
 > 241616831024c9c9fe2b2378b611db0a560b9675

Thanks.  Please try first setting 'frame-inhibit-implied-resize' to t
which should avoid that a frame gets resized when the menu bar is
enabled or disabled (this time I have slightly more hope that it fixes
your problem).

If this does not help, please proceed as follows: Try to undo that
commit (I cite it below) and please first run without the commit under
gdb with a breakpoint at the line

       adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);

in xg_update_frame_menubar.  Please note all values you see after doing

p req.height

whenever you hit that breakpoint (here the value is 27 all the time) -
that is when you create the initial frame and after C-x 5 2.  Then
restore current master and repeat the same steps.  When the values
differ, this should tell us something about what happens.

martin

--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -4141,7 +4141,7 @@ xg_update_frame_menubar (struct frame *f)
    g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
    gtk_widget_show_all (x->menubar_widget);
    gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
-  req.height *= xg_get_scale (f);
+  req.height *= scale;

  #if !defined HAVE_PGTK && defined HAVE_GTK3
    if (FRAME_DISPLAY_INFO (f)->n_planes == 32)
@@ -4154,9 +4154,9 @@ xg_update_frame_menubar (struct frame *f)
      }
  #endif

-  if (FRAME_MENUBAR_HEIGHT (f) != (req.height * scale))
+  if (FRAME_MENUBAR_HEIGHT (f) != req.height)
      {
-      FRAME_MENUBAR_HEIGHT (f) = req.height * scale;
+      FRAME_MENUBAR_HEIGHT (f) = req.height;
        adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
      }
    unblock_input ();

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]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On Thu, 5 Sept 2024 at 08:49, martin rudalics <rudalics@gmx.at> wrote:

>  > My bisection suggests the problematic commit is
>  > 241616831024c9c9fe2b2378b611db0a560b9675
>
> Thanks.  Please try first setting 'frame-inhibit-implied-resize' to t
> which should avoid that a frame gets resized when the menu bar is
> enabled or disabled


Setting the variable to t does indeed prevent the frame being resized when
menu-bar-mode is toggled, but has no effect on the size of the subsequent
windows created.

If this does not help, please proceed as follows: Try to undo that
> commit (I cite it below)


I checked out git master HEAD (currently df57e44a08f) and reverted commit
241616831024c9c9fe2b2378b611db0a560b9675 on top of that.

and please first run without the commit under
> gdb with a breakpoint at the line
>
>        adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
>
> in xg_update_frame_menubar.  Please note all values you see after doing
>
> p req.height
>

50 (before initial frame opens)
50 (after C-x 5 2, before second frame opens)

And the second frame opens at the expected size, the same size as the first.

Then restore current master and repeat the same steps.  When the values
> differ, this should tell us something about what happens.
>

50 (before initial frame opens)
50 (after C-x 5 2, before second frame opens)

But the second frame opens small.

[-- Attachment #2: Type: text/html, Size: 3531 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > I checked out git master HEAD (currently df57e44a08f) and reverted commit
 > 241616831024c9c9fe2b2378b611db0a560b9675 on top of that.

Good.

 > and please first run without the commit under
 >> gdb with a breakpoint at the line
 >>
 >>         adjust_frame_size (f, -1, -1, 2, 0, Qmenu_bar_lines);
 >>
 >> in xg_update_frame_menubar.  Please note all values you see after doing
 >>
 >> p req.height
 >>
 >
 > 50 (before initial frame opens)
 > 50 (after C-x 5 2, before second frame opens)
 >
 > And the second frame opens at the expected size, the same size as the first.
 >
 > Then restore current master and repeat the same steps.  When the values
 >> differ, this should tell us something about what happens.
 >>
 >
 > 50 (before initial frame opens)
 > 50 (after C-x 5 2, before second frame opens)
 >
 > But the second frame opens small.

Inexplicable to me.  Please conduct both runs once more.  But rather
than using the debugger simply evaluate

(setq frame-size-history '(100))

in the initial frame, do C-x 5 2, evaluate

(frame--size-history)

and post the contents of the the buffer *frame-size-history* for each
run here.  Maybe we can see some difference then.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 4175 bytes --]

On Fri, 6 Sept 2024 at 08:54, martin rudalics <rudalics@gmx.at> wrote:

>
> Inexplicable to me.  Please conduct both runs once more.  But rather
> than using the debugger simply evaluate
>
> (setq frame-size-history '(100))
>
> in the initial frame, do C-x 5 2, evaluate
>
> (frame--size-history)
>
> and post the contents of the the buffer *frame-size-history* for each
> run here.  Maybe we can see some difference then.


Buffer contents for master HEAD after C-x 5 2:

Frame size history of #<frame  *Minibuf-1* 0x5a93cc9332e8>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x340, DS=1328x1260
tool-bar-lines (2), NS=1328x1260~>400x340, MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340
ConfigureNotify, PS=1328x1260, XS=400x340, DS=400x340
xg_frame_resized, changed, PS=1328x1260, XS=400x340, DS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x340, DS=400x340
change_frame_size (5), TS=1280x1260~>352x340, TC=80x36~>22x9,
NS=1328x1260~>400x340, IS=1328x1260~>400x340, MS=32x70 IH IV
ConfigureNotify, PS=400x340, XS=400x374
xg_frame_resized, changed, PS=400x340, XS=400x374
change_frame_size_1, delayed, PS=400x340, XS=400x374
change_frame_size (5), TS=352x340~>352x374, TC=22x9~>22x10,
NS=400x340~>400x374, IS=400x340~>400x374, MS=32x70 IH IV
ConfigureNotify, PS=400x374, XS=1280x1354
xg_frame_resized, changed, PS=400x374, XS=1280x1354
change_frame_size_1, delayed, PS=400x374, XS=1280x1354
change_frame_size (5), TS=352x374~>1232x1354, TC=22x10~>77x38,
NS=400x374~>1280x1354, IS=400x374~>1280x1354, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV

And again, but with commit 24161683102 reverted:

Frame size history of #<frame  *Minibuf-1* 0x5f6dbd4449c0>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
menu-bar-lines (2), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x322, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=400x322
change_frame_size_1, delayed, PS=1328x1260, XS=400x322, DS=1328x1260
change_frame_size (5), TS=1280x1260~>352x322, TC=80x36~>22x9,
NS=1328x1260~>400x322, IS=1328x1260~>400x322, MS=32x70 IH IV
ConfigureNotify, PS=400x322, XS=1328x1258
xg_frame_resized, changed, PS=400x322, XS=1328x1258
change_frame_size_1, delayed, PS=400x322, XS=1328x1258
tool-bar-lines (2), NS=400x322~>1328x1258, MS=160x175
xg_frame_set_char_size, visible, PS=400x322, XS=1328x1258, DS=1328x1258
ConfigureNotify, PS=400x322, XS=1328x1258, DS=1328x1258
xg_frame_resized, changed, PS=400x322, XS=1328x1258, DS=1328x1258
change_frame_size_1, delayed, PS=400x322, XS=1328x1258, DS=1328x1258
change_frame_size (5), TS=352x322~>1280x1258, TC=22x9~>80x35,
NS=400x322~>1328x1258, IS=400x322~>1328x1258, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 5728 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Buffer contents for master HEAD after C-x 5 2:

I can't figure out what's going on.  We get a

ConfigureNotify, PS=400x374, XS=1280x1354

event that tells us to set the frame to some "reasonable" size at least.
And the penultimate lines

 > change_frame_size (5), TS=352x374~>1232x1354, TC=22x10~>77x38,
 > NS=400x374~>1280x1354, IS=400x374~>1280x1354, MS=32x70 IH IV

tell, for example, that the text size of the frame should increase from
22x10 columns/lines to 77x38 (38 being obviously too large).  But
apparently nothing changes which is a complete mystery because

- if the WM does give us the indicated new size and we do not react, you
   should at least see an excessive frame border around or a much too
   long title bar above the contents of the new frame,

- if the WM only pretended to give us the indicated new size, you should
   see the new frame clipped at the right and bottom.

Since neither of these apparently happen, I'm clueless.  Could you do
the following: adjust_frame_size (in frame.c) contains the line

   if (new_inner_width != old_inner_width)

Please put a breakpoint there and look what happens when new_inner_width
is 1280.  That is, use

condition B new_inner_width == 1280

where B is the number of the breakpoint you've set.  I'm mostly
interested in whether the breakpoint gets hit at all.  If it does get
hit, we can try to dig further.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

On Fri, 6 Sept 2024 at 10:50, martin rudalics <rudalics@gmx.at> wrote:

>  > Buffer contents for master HEAD after C-x 5 2:
>
> I can't figure out what's going on.


I couldn't make sense of the results I sent either, so I re-ran the tests.

Buffer contents after C-x 5 2 with commit 24161683102 reverted:

Frame size history of #<frame  *Minibuf-1* 0x5b1397209180>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
menu-bar-lines (2), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x322, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=400x322
change_frame_size_1, delayed, PS=1328x1260, XS=400x322, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=400x322
xg_frame_resized, changed, PS=1328x1260, XS=1328x1258, DS=400x322
change_frame_size_1, delayed, PS=1328x1260, XS=1328x1258, DS=400x322
tool-bar-lines (2), NS=1328x1260~>1328x1258, MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1258, DS=1328x1258
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1258
xg_frame_resized, changed, PS=1328x1260, XS=1328x1258, DS=1328x1258
change_frame_size_1, delayed, PS=1328x1260, XS=1328x1258, DS=1328x1258
change_frame_size (5), TS=1280x1260~>1280x1258, TC=80x36~>80x35,
NS=1328x1260~>1328x1258, IS=1328x1260~>1328x1258, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV

With git master HEAD:

Frame size history of #<frame  *Minibuf-1* 0x5e9870140918>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x340, DS=1328x1260
tool-bar-lines (2), NS=1328x1260~>400x340, MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340
ConfigureNotify, PS=1328x1260, XS=400x340, DS=400x340
xg_frame_resized, changed, PS=1328x1260, XS=400x340, DS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x340, DS=400x340
change_frame_size (5), TS=1280x1260~>352x340, TC=80x36~>22x9,
NS=1328x1260~>400x340, IS=1328x1260~>400x340, MS=32x70 IH IV
ConfigureNotify, PS=400x340, XS=400x374
xg_frame_resized, changed, PS=400x340, XS=400x374
change_frame_size_1, delayed, PS=400x340, XS=400x374
change_frame_size (5), TS=352x340~>352x374, TC=22x9~>22x10,
NS=400x340~>400x374, IS=400x340~>400x374, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV

Now the change_frame_size(5) initial and final sizes look correct.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 5244 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Now the change_frame_size(5) initial and final sizes look correct.

OK.  In the next step I'd like to isolate the menubar code as the sole
culprit for what's going in.  Please with master do

(setq default-frame-alist '((width . 200)))

or some other insanely large value so we can see whether we can make the
GTK error disappear this way.  And please apply the trivial patch

diff --git a/src/xfns.c b/src/xfns.c
index 3f0d8f3fcd0..c90ac9c0d37 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5230,7 +5230,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,

    gui_default_parameter (f, parms, Qmenu_bar_lines,
                           NILP (Vmenu_bar_mode)
-                         ? make_fixnum (0) : make_fixnum (1),
+                         ? make_fixnum (0) : make_fixnum (0),
                           NULL, NULL, RES_TYPE_NUMBER);
    gui_default_parameter (f, parms, Qtab_bar_lines,
                           NILP (Vtab_bar_mode)
@@ -5342,7 +5342,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,

  #if defined (USE_X_TOOLKIT) || defined (USE_GTK)
    /* Create the menu bar.  */
-  if (!minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
+  if (0) // !minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
      {
        /* If this signals an error, we haven't set size hints for the
  	 frame and we didn't make it visible.  */

and do C-x 5 2.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Fri, 6 Sept 2024 at 15:16, martin rudalics <rudalics@gmx.at> wrote:

>
> OK.  In the next step I'd like to isolate the menubar code as the sole
> culprit for what's going in.  Please with master do
>
> (setq default-frame-alist '((width . 200)))
>

It takes effect on the initial frame, but doesn't affect the size of the
frame opened with C-x 5 2, or remove the gtk error message:

(emacs:2091071): Gtk-CRITICAL **: 15:57:43.714:
gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

(Just to confirm: I put this setting in early-init.el.)

I then applied the trivial patch you gave to git master HEAD, ran 'emacs
-Q' and did C-x 5 2, and got a small window as usual, but with no error
message in the terminal.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > I then applied the trivial patch you gave to git master HEAD, ran 'emacs
 > -Q' and did C-x 5 2, and got a small window as usual, but with no error
 > message in the terminal.

Let's try to continue from here.  Instead of the "trivial" patch please
now use

diff --git a/src/xfns.c b/src/xfns.c
index 3f0d8f3fcd0..e47f5219a6f 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5340,7 +5340,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
    gui_default_parameter (f, parms, Qno_accept_focus, Qnil,
                           NULL, NULL, RES_TYPE_BOOLEAN);

-#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
+#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
    /* Create the menu bar.  */
    if (!minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
      {

Do you see any error message in the terminal?  Now set

(setq default-frame-alist '((menu-bar-lines . 0)))

and do C-x 5 2.  How does that behave?

martin

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]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Sat, 7 Sept 2024 at 09:37, martin rudalics <rudalics@gmx.at> wrote:

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


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

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1695 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

On Sun, 8 Sept 2024 at 09:42, martin rudalics <rudalics@gmx.at> wrote:

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

Where could we go from here?
>

(I comment below where I think I may have useful input.)

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

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.

(4) Look for other causes.  Could scaling be involved?


My GNOME desktop is scaled by 200%, so it could be.


> (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.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3293 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Sun, 8 Sept 2024 at 15:21, martin rudalics <rudalics@gmx.at> wrote:

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

I don't think so, no.

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.


There isn't one.


> Can you try not using any scaling experimentally?  Jan always complained
> that GTK does not handle scaling orderly (that is, in our sense).
>

I changed scaling to 100%, and it doesn't make any difference.

Thanks for the explanations of the other points.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > 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.
 >
 >
 > There isn't one.

Silly me.  You have to evaluate

(frame--size-history)

first.  Then it should be there.

 > I changed scaling to 100%, and it doesn't make any difference.

Another pipe dream gone.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

On Sun, 8 Sept 2024 at 17:54, martin rudalics <rudalics@gmx.at> wrote:

>  > 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.
>  >
>  >
>  > There isn't one.
>
> Silly me.  You have to evaluate
>
> (frame--size-history)
>
> first.  Then it should be there.
>

Yes, sorry, I didn't think of it either. Here's the output:

Frame size history of #<frame  *Minibuf-1* - GNU Emacs at ecls
0x59a9a967e790>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, unchanged, PS=1328x1260, XS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=1328x1258
change_frame_size_1, delayed, PS=1328x1260, XS=1328x1258, DS=1328x1260
change_frame_size (5), TS=1280x1260~>1280x1258, TC=80x36~>80x35,
NS=1328x1260~>1328x1258, IS=1328x1260~>1328x1258, MS=32x70 IH IV
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1258, XS=1328x1258
ConfigureNotify, PS=1328x1258, XS=1328x1258
xg_frame_resized, unchanged, PS=1328x1258, XS=1328x1258
ConfigureNotify, PS=1328x1258, XS=1280x1354
xg_frame_resized, changed, PS=1328x1258, XS=1280x1354
change_frame_size_1, delayed, PS=1328x1258, XS=1280x1354
change_frame_size (5), TS=1280x1258~>1232x1354, TC=80x35~>77x38,
NS=1328x1258~>1280x1354, IS=1328x1258~>1280x1354, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3437 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]

The important fact is that in the entire sequence of the initial frame's
setup you never experience one of those strange ConfigureNotify events
asking to shrink the frame.  Why they happen only for subsequent frame
creations will probably remain a mystery.

A new mystery is that your creation of the initial frame has one
xg_frame_set_char_size call followed by two ConfigureNotify events where
the first event asks for 1328x1260 and the second one for 1328x1258
pixels.  The same happens again after setting up the tool bar only that
there the first event has 1328x1258 (which matches the previous) and the
second one asks for 1280x1354 pixels.  In the first event
xg_frame_resized concludes that nothing changed, in the second event it
notices a change.

When I do the same thing on my system I get

Frame size history of #<frame *scratch* - GNU Emacs at restno 0x1f668c0>
x_create_frame_1 (5), TS=80x25~>720x550, NS=80x25~>736x550, IS=80x25~>736x550, MS=18x44 IH IV
gui_figure_window_size (5), TS=720x550~>720x792, TC=80x25~>80x36, NS=736x550~>736x792, IS=736x550~>736x792, MS=18x44 IH IV
scroll-bar-width (3), NS=736x792~>752x792, IS=736x792~>752x792, MS=90x110
scroll-bar-height (3), MS=90x110
x_create_frame_2 (0), MS=90x110
xg_frame_set_char_size, invisible, PS=752x792, XS=752x792, DS=752x792
xg_frame_set_char_size (5), MS=18x44 IH IV
MapNotify, not hidden & not iconified, PS=752x792, DS=752x792
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
xg_frame_resized, unchanged, PS=752x792, XS=752x792
menu-bar-lines (2), MS=90x110
xg_frame_set_char_size, visible, PS=752x792, XS=752x792, DS=752x792
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
xg_frame_resized, unchanged, PS=752x792, XS=752x792
tool-bar-lines (2), MS=90x110
xg_frame_set_char_size, visible, PS=752x792, XS=752x792, DS=752x792
ConfigureNotify, PS=752x792, XS=752x792, DS=752x792
xg_frame_resized, unchanged, PS=752x792, XS=752x792

and the sizes requested by xg_frame_set_char_size and the ones received
by ConfigureNotify remain the same throughout - 752x792.

I have no hope that anyone will tell us what's going on here.  Hence
this new mystery will remain unsolved too, I presume.  But maybe I'm
missing an important detail here.

I forgot whether creating an initial frame without menubar works
reasonably on your system.  So please do the same once more but this
time with --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
appended to your emacs call.  This will conclude our experiments with
the history of the initial frame.

Next let's try the following: Upon receiving a ConfigureNotify event we
don't call change_frame_size when _we_ conclude that nothing has
changed.  This conclusion might be wrong so let's _always_ process a
ConfigureNotify event via change_frame_size with the trivial patch I
attached as gtkutil-change.diff.

If this doesn't accomplish anything (as I'd expect), let's try to be
stubborn.  For this purpose apply the less trivial patch attached as
gtkutil-reject.diff, do

(setq frame-size-history '(100))

C-x 5 2

(frame--size-history)

and tell me what *frame-size-history* says in the new frame (if we're
unlucky and I did something wrong, this might get your Emacs run into an
infinite loop and you have to kill it by external means).

martin

[-- Attachment #2: gtkutil-reject.diff --]
[-- Type: text/x-patch, Size: 2506 bytes --]

diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..c5c99d6f1bd 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,49 @@ xg_set_geometry (struct frame *f)
     }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
     pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+      && width != last_resize_width
+      && height != last_resize_height
+      && last_resize_count <= 3)
+    /* We did not get what we wanted, retry.  */
+    {
+      if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+      if (FRAME_GTK_OUTER_WIDGET (f))
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   last_resize_width, last_resize_height);
+      else
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     last_resize_width, last_resize_height);
+
+      last_resize_count++;
+
+      return;
+    }
+  else
+    /* We either got what we asked for or lost the battle.  */
+    {
+      last_resize_frame = NULL;
+      last_resize_height = -1;
+      last_resize_width = -1;
+      last_resize_count = 0;
+    }
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
       || height != FRAME_PIXEL_HEIGHT (f)
@@ -1300,16 +1338,17 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
       gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
+      last_resize_frame = f;
+      last_resize_height = outer_height;
+      last_resize_width = outer_width;
+      last_resize_count = 0;
+
       if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			     outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
       else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-				       outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     outer_width, outer_height);
 #endif
       fullscreen = Qnil;
     }

[-- Attachment #3: gtkutil-change.diff --]
[-- Type: text/x-patch, Size: 1786 bytes --]

diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..68ae38550e0 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1135,12 +1135,12 @@ xg_set_geometry (struct frame *f)
 xg_frame_resized (struct frame *f, int width, int height)
 {
   /* Ignore case where size of native rectangle didn't change.  */
-  if (width != FRAME_PIXEL_WIDTH (f)
-      || height != FRAME_PIXEL_HEIGHT (f)
-      || (f->new_size_p
-	  && ((f->new_width >= 0 && width != f->new_width)
-	      || (f->new_height >= 0 && height != f->new_height))))
-    {
+/**   if (width != FRAME_PIXEL_WIDTH (f) **/
+/**       || height != FRAME_PIXEL_HEIGHT (f) **/
+/**       || (f->new_size_p **/
+/** 	  && ((f->new_width >= 0 && width != f->new_width) **/
+/** 	      || (f->new_height >= 0 && height != f->new_height)))) **/
+/**     { **/
       if (CONSP (frame_size_history))
 	frame_size_history_extra
 	  (f, build_string ("xg_frame_resized, changed"),
@@ -1152,13 +1152,13 @@ xg_frame_resized (struct frame *f, int width, int height)
       change_frame_size (f, width, height, false, true, false);
       SET_FRAME_GARBAGED (f);
       cancel_mouse_face (f);
-    }
-  else if (CONSP (frame_size_history))
-    frame_size_history_extra
-      (f, build_string ("xg_frame_resized, unchanged"),
-       FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
-       f->new_size_p ? f->new_width : -1,
-       f->new_size_p ? f->new_height : -1);
+/**     } **/
+/**   else if (CONSP (frame_size_history)) **/
+/**     frame_size_history_extra **/
+/**       (f, build_string ("xg_frame_resized, unchanged"), **/
+/**        FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height, **/
+/**        f->new_size_p ? f->new_width : -1, **/
+/**        f->new_size_p ? f->new_height : -1); **/
 
 }
 

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]

[-- Attachment #1: Type: text/plain, Size: 4550 bytes --]

Thanks for your persistence, Martin!

On Mon, 9 Sept 2024 at 09:58, martin rudalics <rudalics@gmx.at> wrote:

>
> I forgot whether creating an initial frame without menubar works
> reasonably on your system.  So please do the same once more but this
> time with --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
> appended to your emacs call.  This will conclude our experiments with
> the history of the initial frame.
>

So, I'm doing this with git master HEAD still with the patch that changes
frame.c to initialize frame_size_history thus:

  frame_size_history = Fcons (make_fixnum (100), Qnil);

And here is the contents of *frame-size-history*:

Frame size history of #<frame  *Minibuf-1* - GNU Emacs at ecls
0x56eeaaf4faa0>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, unchanged, PS=1328x1260, XS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=1328x1258
change_frame_size_1, delayed, PS=1328x1260, XS=1328x1258, DS=1328x1260
change_frame_size (5), TS=1280x1260~>1280x1258, TC=80x36~>80x35,
NS=1328x1260~>1328x1258, IS=1328x1260~>1328x1258, MS=32x70 IH IV
menu-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1258, XS=1328x1258
ConfigureNotify, PS=1328x1258, XS=1328x1258
xg_frame_resized, unchanged, PS=1328x1258, XS=1328x1258
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1258, XS=1328x1258
ConfigureNotify, PS=1328x1258, XS=1328x1258
xg_frame_resized, unchanged, PS=1328x1258, XS=1328x1258
set_window_configuration (4), MS=160x175 IH IV

(I observe that this seems to behave just like the "vanilla" version of the
test, only there's no menu bar in the initial frame.)


> Next let's try the following: Upon receiving a ConfigureNotify event we
> don't call change_frame_size when _we_ conclude that nothing has
> changed.  This conclusion might be wrong so let's _always_ process a
> ConfigureNotify event via change_frame_size with the trivial patch I
> attached as gtkutil-change.diff.
>

OK, so with just gtkutil-change.diff applied to git master HEAD, I get the
same behaviour as ever when starting 'emacs -Q' and then typing C-x 5 2.

If this doesn't accomplish anything (as I'd expect), let's try to be
> stubborn.  For this purpose apply the less trivial patch attached as
> gtkutil-reject.diff, do
>
> (setq frame-size-history '(100))
>
> C-x 5 2
>
> (frame--size-history)
>
> and tell me what *frame-size-history* says in the new frame


Frame size history of #<frame  *Minibuf-1* 0x6324643cf650>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
xg_frame_resized, changed, PS=1328x1260, XS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x340, DS=1328x1260
tool-bar-lines (2), NS=1328x1260~>400x340, MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=400x340, DS=400x340
ConfigureNotify, PS=1328x1260, XS=400x374, DS=400x340
xg_frame_resized, changed, PS=1328x1260, XS=400x374, DS=400x340
change_frame_size_1, delayed, PS=1328x1260, XS=400x374, DS=400x340
change_frame_size (5), TS=1280x1260~>352x374, TC=80x36~>22x10,
NS=1328x1260~>400x374, IS=1328x1260~>400x374, MS=32x70 IH IV
set_window_configuration (4), MS=160x175 IH IV
set_window_configuration (4), MS=160x175 IH IV

(No infinite loop!)

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 7095 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

 > Thanks for your persistence, Martin!

Thanks for yours!

 > (No infinite loop!)

Obviously.  I modified the PGTK part.  Please try again with what I
attached now.

martin

[-- Attachment #2: gtkutil-reject.diff --]
[-- Type: text/x-patch, Size: 2388 bytes --]

diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..89061245500 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,45 @@ xg_set_geometry (struct frame *f)
     }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
     pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+      && (width != last_resize_width
+	  || height != last_resize_height)
+      && last_resize_count <= 3)
+    /* We did not get what we wanted, retry.  */
+    {
+      if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+      gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+      last_resize_count++;
+
+      return;
+    }
+  else
+    /* We either got what we asked for or lost the battle.  */
+    {
+      last_resize_frame = NULL;
+      last_resize_height = -1;
+      last_resize_width = -1;
+      last_resize_count = 0;
+    }
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
       || height != FRAME_PIXEL_HEIGHT (f)
@@ -1297,19 +1331,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
     {
 #ifndef HAVE_PGTK
+      last_resize_frame = f;
+      last_resize_height = outer_height;
+      last_resize_width = outer_width;
+      last_resize_count = 0;
+
       gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
       if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			     outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
       else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-				       outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     outer_width, outer_height);
 #endif
       fullscreen = Qnil;
     }

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]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Mon, 9 Sept 2024 at 13:33, martin rudalics <rudalics@gmx.at> wrote:

> Obviously.  I modified the PGTK part.  Please try again with what I
> attached now.
>

This makes an obviously visible difference: C-x 5 2 opens a small frame
which immediately becomes large.

Here's the *frame-size-history* buffer:

Frame size history of #<frame  *Minibuf-1* 0x5e56112ccf80>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x374, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1258, DS=664x671
set_window_configuration (4), MS=160x175 IH IV

Note that once more I retained the simple patch to frame.c to set
frame-size-history to (100).

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2732 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

 > This makes an obviously visible difference: C-x 5 2 opens a small frame
 > which immediately becomes large.
 >
 > Here's the *frame-size-history* buffer:
...
 > ConfigureNotify, PS=1328x1260, XS=400x374, DS=1328x1260
 > xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630
 > tool-bar-lines (2), MS=160x175
 > xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
 > xg_frame_resized, rejected, PS=1328x1260, XS=1328x1258, DS=664x671
 > set_window_configuration (4), MS=160x175 IH IV
 >
 > Note that once more I retained the simple patch to frame.c to set
 > frame-size-history to (100).

Setting 'frame-size-history' to '(100), doing C-x 5 2 and evaluating
'frame--size-history' should be enough.  The frame.c change is needed
only for the initial frame because at that time no Lisp was evaluated.

The result is not yet what I hoped for.  We reject two ConfigureNotify
events but the ensuing xg_frame_set_char_size calls do not get us a
ConfigureNotify we'd accept.  IIUC the final height may be off by two
pixels.  What does (frame-text-height) return for the first and the
second frame?  Also I hope you didn't get the GTK assertion failure.
And how does removing the menubar behave?

Now something completely different.  A couple of years ago I noticed
that our size hints calculations are fundamentally wrong.  I tried to
fix them and I attach some parts of that fix together with the previous
changes I proposed.  Attached as size_hints.diff.  If the patch does not
apply, complain.  I edited it by hand to exclude other changes I made
and I might have made mistakes.  Again I'm interested in the history of
the second frame.

martin

[-- Attachment #2: size_hints.diff --]
[-- Type: text/x-patch, Size: 13370 bytes --]

diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..7a5cf8e32e1 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,45 @@ xg_set_geometry (struct frame *f)
     }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
     pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+      && (width != last_resize_width
+	  || height != last_resize_height)
+      && last_resize_count <= 3)
+    /* We did not get what we wanted, retry.  */
+    {
+      if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+      gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+      last_resize_count++;
+
+      return;
+    }
+  else
+    /* We either got what we asked for or lost the battle.  */
+    {
+      last_resize_frame = NULL;
+      last_resize_height = -1;
+      last_resize_width = -1;
+      last_resize_count = 0;
+    }
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
       || height != FRAME_PIXEL_HEIGHT (f)
@@ -1199,7 +1233,7 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   outer_height /= xg_get_scale (f);
   outer_width /= xg_get_scale (f);
 
-  xg_wm_set_size_hint (f, 0, 0);
+  xg_wm_set_size_hint (f, 0, 0, width, height);
 
   /* Resize the top level widget so rows and columns remain constant.
 
@@ -1297,19 +1331,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
     {
 #ifndef HAVE_PGTK
+      last_resize_frame = f;
+      last_resize_height = outer_height;
+      last_resize_width = outer_width;
+      last_resize_count = 0;
+
       gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
       if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			     outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
       else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-				       outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     outer_width, outer_height);
 #endif
       fullscreen = Qnil;
     }
@@ -1910,14 +1945,16 @@ xg_free_frame_widgets (struct frame *f)
     }
 }
 
-/* Set the normal size hints for the window manager, for frame F.
-   FLAGS is the flags word to use--or 0 meaning preserve the flags
-   that the window now has.
-   If USER_POSITION, set the User Position
-   flag (this is useful when FLAGS is 0).  */
+/** Set the normal size hints for the window manager, for frame F.
+    FLAGS is the flags word to use--or 0 meaning preserve the flags
+    that the window now has.
+    If USER_POSITION, set the User Position
+    flag (this is useful when FLAGS is 0).
+    WIDTH and HEIGHT are the native pixel sizes for F.  */
 
 void
-xg_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
+xg_wm_set_size_hint (struct frame *f, long int flags, bool user_position,
+		     int width, int height)
 {
   /* Must use GTK routines here, otherwise GTK resets the size hints
      to its own defaults.  */
@@ -1927,6 +1964,9 @@ xg_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
   int win_gravity = f->win_gravity;
   Lisp_Object fs_state, frame;
   int scale = xg_get_scale (f);
+  int hor_fix = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
+  int ver_fix = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 0);
+  int rest_width = 0, rest_height = 0;
 
   /* Don't set size hints during initialization; that apparently leads
      to a race condition.  See the thread at
@@ -1936,6 +1976,16 @@ xg_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
       || FRAME_PARENT_FRAME (f))
     return;
 
+  if (width < 0)
+    width = FRAME_PIXEL_WIDTH (f);
+
+  width /= scale;
+
+  if (height < 0)
+    height = FRAME_PIXEL_HEIGHT (f);
+
+  height /= scale;
+
   XSETFRAME (frame, f);
   fs_state = Fframe_parameter (frame, Qfullscreen);
   if ((EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth))
@@ -1963,22 +2013,26 @@ xg_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
   size_hints = f->output_data.xp->size_hints;
   hint_flags = f->output_data.xp->hint_flags;
 
-  hint_flags |= GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
-  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
+  hint_flags |= GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC | GDK_HINT_MIN_SIZE;
+  size_hints.width_inc
+    = frame_resize_pixelwise ? 1 : (FRAME_COLUMN_WIDTH (f) / scale);
+  size_hints.height_inc
+    = frame_resize_pixelwise ? 1 : (FRAME_LINE_HEIGHT (f) / scale);
+
+  base_width = (hor_fix + FRAME_TOOLBAR_WIDTH (f)) / scale;
+  base_height = ((ver_fix + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
+		 / scale);
 
-  hint_flags |= GDK_HINT_BASE_SIZE;
-  /* Use one row/col here so base_height/width does not become zero.
-     Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
-     Obviously this makes the row/col value displayed off by 1.  */
-  base_width = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 1) + FRAME_TOOLBAR_WIDTH (f);
-  base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 1)
-    + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f);
+  /* Now correct the base sizes by what the text equivalents of WIDTH
+     and HEIGHT are not multiples of the size increments.  */
+  rest_width = (width - hor_fix / scale) % size_hints.width_inc;
+  rest_height = (height - ver_fix / scale) % size_hints.height_inc;
+  size_hints.base_width = base_width + rest_width;
+  size_hints.base_height = base_height + rest_height;
 
-  size_hints.base_width = base_width;
-  size_hints.base_height = base_height;
-  size_hints.min_width  = base_width;
-  size_hints.min_height = base_height;
+  /* For GTK2 include the size of external decorations in the minimum
+     sizes, for GTK3 don't do that.  I have no idea why these behave
+     differently (on xfwm4 at least).  */
 
   /* These currently have a one to one mapping with the X values, but I
      don't think we should rely on that.  */
@@ -2018,11 +2072,6 @@ xg_wm_set_size_hint (struct frame *f, long int flags, bool user_position)
       hint_flags |= GDK_HINT_USER_POS;
     }
 
-  size_hints.base_width /= scale;
-  size_hints.base_height /= scale;
-  size_hints.width_inc /= scale;
-  size_hints.height_inc /= scale;
-
   if (hint_flags != f->output_data.xp->hint_flags
       || memcmp (&size_hints,
 		 &f->output_data.xp->size_hints,
diff --git a/src/gtkutil.h b/src/gtkutil.h
index b689053b4b8..cf1adf0d606 100644
--- a/src/gtkutil.h
+++ b/src/gtkutil.h
@@ -153,7 +153,7 @@ #define XG_ITEM_DATA "emacs_menuitem"
 extern int xg_get_default_scrollbar_width (struct frame *f);
 extern int xg_get_default_scrollbar_height (struct frame *f);
 
-extern void xg_wm_set_size_hint (struct frame *, long int, bool);
+extern void xg_wm_set_size_hint (struct frame *, long int, bool, int, int);
 
 extern void update_frame_tool_bar (struct frame *f);
 extern void free_frame_tool_bar (struct frame *f);
diff --git a/src/pgtkfns.c b/src/pgtkfns.c
index f0fd3000965..c6379280a1d 100644
--- a/src/pgtkfns.c
+++ b/src/pgtkfns.c
@@ -1645,7 +1645,7 @@ #define INSTALL_CURSOR(FIELD, NAME) \
      badly we want them.  This should be done after we have the menu
      bar so that its size can be taken into account.  */
   block_input ();
-  xg_wm_set_size_hint (f, window_prompting, false);
+  xg_wm_set_size_hint (f, window_prompting, false, -1, -1);
   unblock_input ();
 
   adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
diff --git a/src/pgtkterm.c b/src/pgtkterm.c
index 079945126e0..d16b61b3e9d 100644
--- a/src/pgtkterm.c
+++ b/src/pgtkterm.c
@@ -639,7 +639,7 @@ pgtk_set_offset (struct frame *f, int xoff, int yoff, int change_gravity)
   pgtk_calc_absolute_position (f);
 
   block_input ();
-  xg_wm_set_size_hint (f, 0, false);
+  xg_wm_set_size_hint (f, 0, false, -1, -1);
 
   if (change_gravity != 0)
     {
@@ -686,7 +686,7 @@ pgtk_set_window_size (struct frame *f, bool change_gravity,
 
   f->output_data.pgtk->preferred_width = pixelwidth;
   f->output_data.pgtk->preferred_height = pixelheight;
-  xg_wm_set_size_hint (f, 0, 0);
+  xg_wm_set_size_hint (f, 0, 0, -1, -1);
   xg_frame_set_char_size (f, pixelwidth, pixelheight);
   gtk_widget_queue_resize (FRAME_WIDGET (f));
 
@@ -974,7 +974,7 @@ pgtk_set_parent_frame (struct frame *f, Lisp_Object new_value,
 			      fixed, TRUE, TRUE, 0);
 	  f->output_data.pgtk->preferred_width = alloc.width;
 	  f->output_data.pgtk->preferred_height = alloc.height;
-	  xg_wm_set_size_hint (f, 0, 0);
+	  xg_wm_set_size_hint (f, 0, 0, -1, -1);
 	  xg_frame_set_char_size (f, FRAME_PIXEL_TO_TEXT_WIDTH (f, alloc.width),
 				  FRAME_PIXEL_TO_TEXT_HEIGHT (f, alloc.height));
 	  gtk_widget_queue_resize (FRAME_WIDGET (f));
diff --git a/src/xfns.c b/src/xfns.c
index 3f0d8f3fcd0..92f1567b66a 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -4845,7 +4845,7 @@ DEFUN ("x-wm-set-size-hint", Fx_wm_set_size_hint, Sx_wm_set_size_hint,
   struct frame *f = decode_window_system_frame (frame);
 
   block_input ();
-  x_wm_set_size_hint (f, 0, false);
+  x_wm_set_size_hint (f, 0, false, -1, -1);
   unblock_input ();
   return Qnil;
 }
@@ -5340,7 +5340,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
   gui_default_parameter (f, parms, Qno_accept_focus, Qnil,
                          NULL, NULL, RES_TYPE_BOOLEAN);
 
-#if defined (USE_X_TOOLKIT) || defined (USE_GTK)
+#if defined (USE_X_TOOLKIT) && !defined (USE_GTK)
   /* Create the menu bar.  */
   if (!minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
     {
@@ -5365,7 +5365,7 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
      badly we want them.  This should be done after we have the menu
      bar so that its size can be taken into account.  */
   block_input ();
-  x_wm_set_size_hint (f, window_prompting, false);
+  x_wm_set_size_hint (f, window_prompting, false, -1, -1);
   unblock_input ();
 
   adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
diff --git a/src/xterm.c b/src/xterm.c
index 0c20d38b0f7..4dc50213622 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -27617,7 +27617,7 @@ x_set_offset (struct frame *f, int xoff, int yoff, int change_gravity)
   x_calc_absolute_position (f);
 
   block_input ();
-  x_wm_set_size_hint (f, 0, false);
+  x_wm_set_size_hint (f, 0, false, -1, -1);
 
 #ifdef USE_GTK
   if (x_gtk_use_window_move)
@@ -28318,7 +28318,7 @@ x_check_fullscreen (struct frame *f)
 	  emacs_abort ();
         }
 
-      x_wm_set_size_hint (f, 0, false);
+      x_wm_set_size_hint (f, 0, false,-1, -1);
 
       XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 		     width, height);
@@ -28489,7 +28489,7 @@ x_set_window_size_1 (struct frame *f, bool change_gravity,
 {
   if (change_gravity)
     f->win_gravity = NorthWestGravity;
-  x_wm_set_size_hint (f, 0, false);
+  x_wm_set_size_hint (f, 0, false, width, height);
 
   XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 		 width, height + FRAME_MENUBAR_HEIGHT (f));
@@ -29326,7 +29326,7 @@ x_make_frame_invisible (struct frame *f)
      program-specified, so that when the window is mapped again, it will be
      placed at the same location, without forcing the user to position it
      by hand again (they have already done that once for this window.)  */
-  x_wm_set_size_hint (f, 0, true);
+  x_wm_set_size_hint (f, 0, true, -1, -1);
 
 #ifdef USE_GTK
   if (FRAME_GTK_OUTER_WIDGET (f))
@@ -30049,7 +30049,8 @@ x_embed_frame (struct x_display_info *dpyinfo, struct frame *f)
    The GTK version is in gtkutils.c.  */
 
 void
-x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
+x_wm_set_size_hint (struct frame *f, long flags, bool user_position,
+		    int width, int height)
 {
 #ifndef USE_GTK
   XSizeHints size_hints;
@@ -30228,7 +30229,7 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
 
   XSetWMNormalHints (FRAME_X_DISPLAY (f), window, &size_hints);
 #else
-  xg_wm_set_size_hint (f, flags, user_position);
+  xg_wm_set_size_hint (f, flags, user_position, width, height);
 #endif /* USE_GTK */
 }
 
diff --git a/src/xterm.h b/src/xterm.h
index 8d5c9917749..2b6145a2b14 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -1774,7 +1774,7 @@ #define SELECTION_EVENT_TIME(eventp)	\
 extern void x_make_frame_invisible (struct frame *);
 extern void x_iconify_frame (struct frame *);
 extern void x_free_frame_resources (struct frame *);
-extern void x_wm_set_size_hint (struct frame *, long, bool);
+extern void x_wm_set_size_hint (struct frame *, long, bool, int, int);
 #if defined HAVE_XSYNCTRIGGERFENCE && !defined USE_GTK \
   && defined HAVE_CLOCK_GETTIME
 extern void x_sync_init_fences (struct frame *);

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]

[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]

I've removed the patch to frame.c, and I'm running with:

emacs -Q  --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"

On Mon, 9 Sept 2024 at 17:52, martin rudalics <rudalics@gmx.at> wrote:

>
> The result is not yet what I hoped for.  We reject two ConfigureNotify
> events but the ensuing xg_frame_set_char_size calls do not get us a
> ConfigureNotify we'd accept.  IIUC the final height may be off by two
> pixels.  What does (frame-text-height) return for the first and the
> second frame?

1260 for both.


>   Also I hope you didn't get the GTK assertion failure.
>

Indeed, I do not.


> And how does removing the menubar behave?
>

When I do M-x menu-bar-mode the first time it has no effect, as Emacs
considers the menu bar to be currently enabled, so it disables it.

After that, toggling the menu bar works as expected, and the window gets
taller each time it is enabled, and shorter (by the same amount) each time
it is disabled.

Now something completely different.  A couple of years ago I noticed
> that our size hints calculations are fundamentally wrong.  I tried to
> fix them and I attach some parts of that fix together with the previous
> changes I proposed.  Attached as size_hints.diff.  If the patch does not
> apply, complain.  I edited it by hand to exclude other changes I made
> and I might have made mistakes.  Again I'm interested in the history of
> the second frame.
>

OK, running with just this patch (which applies fine), and doing the
history test, the history of the second frame is:

Frame size history of #<frame  *Minibuf-1* 0x6253825731d0>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x376, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x376, DS=664x630
menu-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1260, DS=664x655
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1260, DS=664x696
set_window_configuration (4), MS=160x175 IH IV

The second window is the same size as the first.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 5492 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

 >> What does (frame-text-height) return for the first and the
 >> second frame?
 >
 > 1260 for both.

Relieving.

 >>    Also I hope you didn't get the GTK assertion failure.
 >>
 >
 > Indeed, I do not.

So the sequence definitely is: For some inexplicable reason we receive a
ConfigureNotify event that tells us that the frame has become very
small.  We accept the new size, adjust our frame accordingly and use the
new size as base for the next resize request.  When we issue that
request, GTK complains that it cannot fit the menubar and issues the
assertion failure.

 > When I do M-x menu-bar-mode the first time it has no effect, as Emacs
 > considers the menu bar to be currently enabled, so it disables it.

Since you run with

emacs -Q  --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"

Emacs considers menu bars to be currently enabled "globally" and
disabling them globally has no effect on that frame.  Do you agree with
this explanation?

 > OK, running with just this patch (which applies fine), and doing the
 > history test, the history of the second frame is:
...
 > ConfigureNotify, PS=1328x1260, XS=400x376, DS=1328x1260
 > xg_frame_resized, rejected, PS=1328x1260, XS=400x376, DS=664x630

The 400x376 are as before so other size hints won't fix anything (but we
inherently checked that when running with 'frame-resize-pixelwise'
before).

 > menu-bar-lines (2), MS=160x175
 > xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > xg_frame_resized, rejected, PS=1328x1260, XS=1328x1260, DS=664x655

But this one ...

 > tool-bar-lines (2), MS=160x175
 > xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > ConfigureNotify, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > xg_frame_resized, rejected, PS=1328x1260, XS=1328x1260, DS=664x696

... and this one are obviously fishy.  The sizes apparently match, so
why reject them?  The reason is that I recorded scaled sizes in what
appear after DS.  Since you have a scaling factor of 2 and (* 2 664)
gives 1328 this explains the width value.  The height value is likely as
(- (* 2 696) 132) giving 1260 where 132 is the height of your tool bar
(I extracted that from your previous call of 'frame-geometry').  If
there were a menu bar, we would have to subtract another 50 pixels.

So please try again with the attached patch which records the original
unscaled sizes.  And please tell me what

(frame-char-width)
(frame-char-height)

evaluate to.  I'm still trying to explain the 400x376 values.

martin

[-- Attachment #2: gtkutil-reject.diff --]
[-- Type: text/x-patch, Size: 2376 bytes --]

diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..f5022411dab 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,45 @@ xg_set_geometry (struct frame *f)
     }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
     pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+      && (width != last_resize_width
+	  || height != last_resize_height)
+      && last_resize_count <= 3)
+    /* We did not get what we wanted, retry.  */
+    {
+      if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+      gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+      last_resize_count++;
+
+      return;
+    }
+  else
+    /* We either got what we asked for or lost the battle.  */
+    {
+      last_resize_frame = NULL;
+      last_resize_height = -1;
+      last_resize_width = -1;
+      last_resize_count = 0;
+    }
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
       || height != FRAME_PIXEL_HEIGHT (f)
@@ -1297,19 +1331,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
     {
 #ifndef HAVE_PGTK
+      last_resize_frame = f;
+      last_resize_height = height;
+      last_resize_width = width;
+      last_resize_count = 0;
+
       gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
       if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			     outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
       else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-				       outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     outer_width, outer_height);
 #endif
       fullscreen = Qnil;
     }

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]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Tue, 10 Sept 2024 at 10:32, martin rudalics <rudalics@gmx.at> wrote:

>
> Since you run with
>
> emacs -Q  --eval "(setq default-frame-alist '((menu-bar-lines . 0)))"
>
> Emacs considers menu bars to be currently enabled "globally" and
> disabling them globally has no effect on that frame.  Do you agree with
> this explanation?
>

I would be more cautious, since I do not know the code, and simply say that
disabling menu-bar-mode has no effect on the current frame, where there is
already no menu bar.

So please try again with the attached patch which records the original
> unscaled sizes.  And please tell me what
>
> (frame-char-width)
> (frame-char-height)
>
> evaluate to.
>

Can I just check: do you want me to apply your latest gtkutil-reject.diff
on top of your previous size_hints.diff, or instead of it?

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2157 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Can I just check: do you want me to apply your latest gtkutil-reject.diff
> on top of your previous size_hints.diff, or instead of it?

Instead of it.

martin

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]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Tue, 10 Sept 2024 at 18:16, martin rudalics <rudalics@gmx.at> wrote:

> > Can I just check: do you want me to apply your latest gtkutil-reject.diff
> > on top of your previous size_hints.diff, or instead of it?
>
> Instead of it.
>

Here is the frame size history:

Frame size history of #<frame  *Minibuf-1* 0x56bbf9520158>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x340, DS=1328x1260
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=2560x1346, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=2560x1346, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=2560x1326, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=2560x1326, DS=1328x1260
set_window_configuration (4), MS=160x175 IH IV

Note that something quite different happens when I open the second frame:
it ends up full screen, but the Emacs window only occupies the same space
as the initial window (roughly half the screen wide, and a little shorter
than the screen).

frame-char-width: 16
frame-char-height: 35

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3015 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

 > Here is the frame size history:

Thanks.

 > x_create_frame_2 (0), MS=160x175
 > xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > xg_frame_set_char_size (5), MS=32x70 IH IV
 > x_make_frame_visible
 > MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
 > ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260

Here we go again with the small size, reject it and ask for the previous
size ...

 > xg_frame_resized, rejected, PS=1328x1260, XS=400x340, DS=1328x1260
 > tool-bar-lines (2), MS=160x175
 > xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 > ConfigureNotify, PS=1328x1260, XS=2560x1346, DS=1328x1260

... but now all of a sudden we should handle a frame size about twice as
large which we reject again ...

 > xg_frame_resized, rejected, PS=1328x1260, XS=2560x1346, DS=1328x1260
 > ConfigureNotify, PS=1328x1260, XS=2560x1326, DS=1328x1260
 > xg_frame_resized, rejected, PS=1328x1260, XS=2560x1326, DS=1328x1260
 > set_window_configuration (4), MS=160x175 IH IV
 >
 > Note that something quite different happens when I open the second frame:
 > it ends up full screen, but the Emacs window only occupies the same space
 > as the initial window (roughly half the screen wide, and a little shorter
 > than the screen).

... and never fill accordingly because we don't like it.  This was a bad
idea.  The second call of gtk_window_resize simply has to get the same
dimensions as the first one as in the first version of this patch.

Just that the "first version" of this patch had another problem: The
sizes we ask for in gtk_window_resize via outer_height and outer_width
include tool and menu bars.  The sizes reported by ConfigureNotify are
those of the native rectangle only.  I hopefully fixed that now.  Please
try again and tell me the histories you get here for the initial frame
and the second frame both with and without the menu bar by evaluating
(frame--size-history).

 > frame-char-width: 16
 > frame-char-height: 35

Times twice gets us the MS=32x70 above.

Next I'd like to know what you see with

(let ((frame (make-frame '((visibility . nil)))))
   (make-frame-visible frame))

and

(let ((frame (make-frame '((visibility . nil) (menu-bar-lines . 0)))))
   (make-frame-visible frame))

both with an unpatched Emacs and a patched one.  Here the second frame
appears exactly where the first one is, so we would have to care about
the placement ourselves.

I only want to know whether this "visibly" improves the behavior you
observe (no need to look at the history of these frames).  The idea is
that we could make creation of the second frame smoother so that you
don't see its initial size.

martin

[-- Attachment #2: gtkutil-reject.diff --]
[-- Type: text/x-patch, Size: 3812 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 7f4bf274ad9..6b6f6aa3c5c 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -6769,7 +6769,7 @@ focus (where a frame immediately loses focus when it's left by the mouse
 
 The function `frame--size-history' displays the value of this variable
 in a more readable form.  */);
-    frame_size_history = Qnil;
+  frame_size_history = Fcons (make_fixnum (100), Qnil);
 
   DEFVAR_BOOL ("tooltip-reuse-hidden-frame", tooltip_reuse_hidden_frame,
 	       doc: /* Non-nil means reuse hidden tooltip frames.
diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..649cc3c8030 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,47 @@ xg_set_geometry (struct frame *f)
     }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
     pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+      && (width != last_resize_width - FRAME_TOOLBAR_WIDTH (f)
+	  || height != (last_resize_height
+			- FRAME_MENUBAR_HEIGHT (f)
+			- FRAME_TOOLBAR_HEIGHT (f)))
+      && last_resize_count <= 3)
+    /* We did not get what we wanted, retry.  */
+    {
+      if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+      gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+      last_resize_count++;
+
+      return;
+    }
+  else
+    /* We either got what we asked for or lost the battle.  */
+    {
+      last_resize_frame = NULL;
+      last_resize_height = -1;
+      last_resize_width = -1;
+      last_resize_count = 0;
+    }
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
       || height != FRAME_PIXEL_HEIGHT (f)
@@ -1297,19 +1333,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
     {
 #ifndef HAVE_PGTK
+      last_resize_frame = f;
+      last_resize_width = outer_width;
+      last_resize_height = outer_height;
+      last_resize_count = 0;
+
       gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
       if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			     outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
       else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-				       outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     outer_width, outer_height);
 #endif
       fullscreen = Qnil;
     }
@@ -1327,10 +1364,16 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   if (FRAME_VISIBLE_P (f) && !was_visible)
     {
       if (CONSP (frame_size_history))
-	frame_size_history_extra
-	  (f, build_string ("xg_frame_set_char_size, visible"),
-	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
-	   f->new_width, f->new_height);
+	{
+	  frame_size_history_extra
+	    (f, build_string ("xg_frame_set_char_size, visible"),
+	     FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	     f->new_width, f->new_height);
+
+	  if (gwidth > 0 || gheight > 0)
+	    frame_size_history_extra
+	      (f, build_string (" gvalues"), gwidth, gheight, -1, -1, -1, -1);
+	}
 
       /* Must call this to flush out events */
       (void)gtk_events_pending ();

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]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

On Sat, 14 Sept 2024 at 15:43, martin rudalics <rudalics@gmx.at> wrote:

>
> Just that the "first version" of this patch had another problem: The
> sizes we ask for in gtk_window_resize via outer_height and outer_width
> include tool and menu bars.  The sizes reported by ConfigureNotify are
> those of the native rectangle only.  I hopefully fixed that now.  Please
> try again and tell me the histories you get here for the initial frame
> and the second frame both with and without the menu bar by evaluating
> (frame--size-history).
>

History without menu bar:

Frame size history of #<frame  *Minibuf-1* 0x6220fb2af828>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x374, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 gvalues, PS=200x187
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1258, DS=664x671
set_window_configuration (4), MS=160x175 IH IV

History with menu bar:

Frame size history of #<frame  *Minibuf-1* 0x56319385af48>
x_create_frame_1 (5), TS=80x25~>1280x875, NS=80x25~>1296x875,
IS=80x25~>1296x875, MS=32x70 IH IV
gui_figure_window_size (5), TS=1280x875~>1280x1260, TC=80x25~>80x36,
NS=1296x875~>1296x1260, IS=1296x875~>1296x1260, MS=32x70 IH IV
scroll-bar-width (3), NS=1296x1260~>1328x1260, IS=1296x1260~>1328x1260,
MS=160x175
scroll-bar-height (3), MS=160x175
menu-bar-lines (2), MS=160x175
x_create_frame_2 (0), MS=160x175
xg_frame_set_char_size, invisible, PS=1328x1260, XS=1328x1260, DS=1328x1260
xg_frame_set_char_size (5), MS=32x70 IH IV
x_make_frame_visible
MapNotify, not hidden & not iconified, PS=1328x1260, DS=1328x1260
ConfigureNotify, PS=1328x1260, XS=400x340, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=400x340, DS=664x655
tool-bar-lines (2), MS=160x175
xg_frame_set_char_size, visible, PS=1328x1260, XS=1328x1260, DS=1328x1260
 gvalues, PS=200x195
ConfigureNotify, PS=1328x1260, XS=1328x1258, DS=1328x1260
xg_frame_resized, rejected, PS=1328x1260, XS=1328x1258, DS=664x696
set_window_configuration (4), MS=160x175 IH IV

Next I'd like to know what you see with
>
> (let ((frame (make-frame '((visibility . nil)))))
>    (make-frame-visible frame))
>
> and
>
> (let ((frame (make-frame '((visibility . nil) (menu-bar-lines . 0)))))
>    (make-frame-visible frame))
>
> both with an unpatched Emacs and a patched one.  Here the second frame
> appears exactly where the first one is, so we would have to care about
> the placement ourselves.
>

Unpatched Emacs: both expressions create a small second frame in the top
left-hand corner of the screen.

Patched Emacs: both expressions create a small second frame in the top
left-hand corner of the screen that immediately jumps to being the correct
size.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 5588 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

 > xg_frame_resized, rejected, PS=1328x1260, XS=400x374, DS=664x630

I'm afraid that some mishap has happened here.  The DS=664x630 values
indicate that you've run an older version of the patch where I confused
scaled and unscaled values.  I'm attaching the latest version renamed to
include today's date.  Please retry.

 > Next I'd like to know what you see with
 >>
 >> (let ((frame (make-frame '((visibility . nil)))))
 >>     (make-frame-visible frame))
 >>
 >> and
 >>
 >> (let ((frame (make-frame '((visibility . nil) (menu-bar-lines . 0)))))
 >>     (make-frame-visible frame))
 >>
 >> both with an unpatched Emacs and a patched one.  Here the second frame
 >> appears exactly where the first one is, so we would have to care about
 >> the placement ourselves.
 >>
 >
 > Unpatched Emacs: both expressions create a small second frame in the top
 > left-hand corner of the screen.
 >
 > Patched Emacs: both expressions create a small second frame in the top
 > left-hand corner of the screen that immediately jumps to being the correct
 > size.

I would need a frame size history for one of these to understand why the
frame gets apparently mapped before the last resize.

martin

[-- Attachment #2: gtkutil-reject-2024-09-16.diff --]
[-- Type: text/x-patch, Size: 3812 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 7f4bf274ad9..6b6f6aa3c5c 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -6769,7 +6769,7 @@ focus (where a frame immediately loses focus when it's left by the mouse
 
 The function `frame--size-history' displays the value of this variable
 in a more readable form.  */);
-    frame_size_history = Qnil;
+  frame_size_history = Fcons (make_fixnum (100), Qnil);
 
   DEFVAR_BOOL ("tooltip-reuse-hidden-frame", tooltip_reuse_hidden_frame,
 	       doc: /* Non-nil means reuse hidden tooltip frames.
diff --git a/src/gtkutil.c b/src/gtkutil.c
index d57627f152f..649cc3c8030 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1129,11 +1129,47 @@ xg_set_geometry (struct frame *f)
     }
 }
 
+static struct frame *last_resize_frame = NULL;
+static int last_resize_height = -1;
+static int last_resize_width = -1;
+static int last_resize_count = 0;
+
 /** Function to handle resize of native frame F to WIDTH and HEIGHT
     pixels after we got a ConfigureNotify event.  */
 void
 xg_frame_resized (struct frame *f, int width, int height)
 {
+#ifndef HAVE_PGTK
+  if (f == last_resize_frame
+      && (width != last_resize_width - FRAME_TOOLBAR_WIDTH (f)
+	  || height != (last_resize_height
+			- FRAME_MENUBAR_HEIGHT (f)
+			- FRAME_TOOLBAR_HEIGHT (f)))
+      && last_resize_count <= 3)
+    /* We did not get what we wanted, retry.  */
+    {
+      if (CONSP (frame_size_history))
+	frame_size_history_extra
+	  (f, build_string ("xg_frame_resized, rejected"),
+	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	   last_resize_width, last_resize_height);
+
+      gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			 last_resize_width, last_resize_height);
+
+      last_resize_count++;
+
+      return;
+    }
+  else
+    /* We either got what we asked for or lost the battle.  */
+    {
+      last_resize_frame = NULL;
+      last_resize_height = -1;
+      last_resize_width = -1;
+      last_resize_count = 0;
+    }
+#endif
   /* Ignore case where size of native rectangle didn't change.  */
   if (width != FRAME_PIXEL_WIDTH (f)
       || height != FRAME_PIXEL_HEIGHT (f)
@@ -1297,19 +1333,20 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   else
     {
 #ifndef HAVE_PGTK
+      last_resize_frame = f;
+      last_resize_width = outer_width;
+      last_resize_height = outer_height;
+      last_resize_count = 0;
+
       gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 			 outer_width, outer_height);
 #else
       if (FRAME_GTK_OUTER_WIDGET (f))
-	{
-	  gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-			     outer_width, outer_height);
-	}
+	gtk_window_resize (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+			   outer_width, outer_height);
       else
-	{
-	  gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
-				       outer_width, outer_height);
-	}
+	gtk_widget_set_size_request (FRAME_GTK_WIDGET (f),
+				     outer_width, outer_height);
 #endif
       fullscreen = Qnil;
     }
@@ -1327,10 +1364,16 @@ xg_frame_set_char_size (struct frame *f, int width, int height)
   if (FRAME_VISIBLE_P (f) && !was_visible)
     {
       if (CONSP (frame_size_history))
-	frame_size_history_extra
-	  (f, build_string ("xg_frame_set_char_size, visible"),
-	   FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
-	   f->new_width, f->new_height);
+	{
+	  frame_size_history_extra
+	    (f, build_string ("xg_frame_set_char_size, visible"),
+	     FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f), width, height,
+	     f->new_width, f->new_height);
+
+	  if (gwidth > 0 || gheight > 0)
+	    frame_size_history_extra
+	      (f, build_string (" gvalues"), gwidth, gheight, -1, -1, -1, -1);
+	}
 
       /* Must call this to flush out events */
       (void)gtk_events_pending ();

bug#72986: Disabling menu-bar-mode changes size of new frames

[Eli Zaretskii]

> Date: Tue, 3 Sep 2024 19:03:05 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Po Lu <luangruo@yahoo.com>,
>  72986@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
> mutter doesn't like us.  Just to make sure one thing: Would setting
> 'frame-resize-pixelwise' to t change anything?
> 
> Otherwise I would try to build Emacs with gtk2, lucid or motif.

Isn't it true that disabling menu-bar-mode from the init file avoids
these problems?

Reuben, is running with menu-bar-mode disabled at all a goal of yours,
or you reported this issue simply because it looks like incorrect
behavior, and you don't really care about running without the menu
bar?

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]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Tue, 3 Sept 2024 at 18:44, Eli Zaretskii <eliz@gnu.org> wrote:

> Isn't it true that disabling menu-bar-mode from the init file avoids
> these problems?
>

I don't think so: I had it customized off and had to bisect my
customizations in order to find what was causing the problem.

Reuben, is running with menu-bar-mode disabled at all a goal of yours,
>

Yes!

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 1269 bytes --]

bug#72986: Disabling menu-bar-mode changes size of new frames

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Isn't it true that disabling menu-bar-mode from the init file avoids
 > these problems?

In Reuben's second scenario 'menu-bar-mode' is not disabled.  The second
frame is smaller with the menu bar enabled.

martin