menu-bar-mode makes frame continuously shrink in height

menu-bar-mode makes frame continuously shrink in height

[PierGianLuca]

Hi everyone,

Emacs 29.1 on Ubuntu 20.04 here. Emacs was installed from tarball with options:
--with-native-compilation --with-json --enable-link-time-optimization --with-x-toolkit=lucid --without-toolkit-scroll-bars


I see a curious behaviour from calling "menu-bar-mode" and "tool-bar-mode". Before submitting it as a bug I wanted to ask here if it's something known, or if not how I can track the source of the problem myself.

I have frames set at height=77 in "default-frame-alist", and "menu-bar-mode" and "tool-bar-mode" both set to nil (all via Customize).


(A) If I call "M-x menu-bar-mode", the menu bar appears, and the frame shrinks vertically by one line. If I call "M-x menu-bar-mode" again, the menu bar disappears, and the frame shrinks vertically once more. So the more I make the menu bar appear and disappear, the more the frame shrinks.

I tried adding and removing "menu-bar-lines" in "frame-inhibit-implied-resize", but the problem remains either way.


(B) Exactly the same problem with tool-bar-mode. There's one difference here:

this continuous-shrinking behaviour happens if "tool-bar-lines" is in "frame-inhibit-implied-resize". Otherwise, the frame increases in vertical size when tool-bar-mode is enabled, and decrease to the original size when tool-bar-mode is is disabled. (This seems to me contrary to what's explained under "tool-bar-lines".)


(C) If I call Emacs with "-Q" (no init file), the continuous shrinking does *not* happen with menu-bar-mode – but it *does* happen with tool-bar-mode.


This makes me think that there's both a bug somewhere, but also something strange in my init file.

Appreciate any thoughts or suggestions about which tests to make!

Cheers,
Luca

Re: menu-bar-mode makes frame continuously shrink in height

[Po Lu]

PierGianLuca <luca@magnaspesmeretrix.org> writes:

> Hi everyone,
>
> Emacs 29.1 on Ubuntu 20.04 here. Emacs was installed from tarball with options:
> --with-native-compilation --with-json --enable-link-time-optimization --with-x-toolkit=lucid --without-toolkit-scroll-bars
>
>
> I see a curious behaviour from calling "menu-bar-mode" and "tool-bar-mode". Before submitting it as a bug I wanted to ask here if it's something known, or if not how I can track the source of the problem myself.
>
> I have frames set at height=77 in "default-frame-alist", and "menu-bar-mode" and "tool-bar-mode" both set to nil (all via Customize).
>
>
> (A) If I call "M-x menu-bar-mode", the menu bar appears, and the frame
> shrinks vertically by one line. If I call "M-x menu-bar-mode" again,
> the menu bar disappears, and the frame shrinks vertically once
> more. So the more I make the menu bar appear and disappear, the more
> the frame shrinks.
>
> I tried adding and removing "menu-bar-lines" in "frame-inhibit-implied-resize", but the problem remains either way.
>
>
> (B) Exactly the same problem with tool-bar-mode. There's one difference here:
>
> this continuous-shrinking behaviour happens if "tool-bar-lines" is in
> "frame-inhibit-implied-resize". Otherwise, the frame increases in
> vertical size when tool-bar-mode is enabled, and decrease to the
> original size when tool-bar-mode is is disabled. (This seems to me
> contrary to what's explained under "tool-bar-lines".)
>
>
> (C) If I call Emacs with "-Q" (no init file), the continuous shrinking does *not* happen with menu-bar-mode – but it *does* happen with tool-bar-mode.
>
>
> This makes me think that there's both a bug somewhere, but also something strange in my init file.

More likely, your window manager is imposing stringent size requirements
pursuant to the resize increments Emacs has requested.  Do frames
continue to shrink after setting frame-resize-pixelwise to t in
early-init.el?

Re: 4 pixels missing at startup (was: menu-bar-mode makes frame continuously shrink in height)

[PierGianLuca]

Hi Po, thank you for the feedback. Something else interesting is coming up:

> Do frames
> continue to shrink after setting frame-resize-pixelwise to t in
> early-init.el?

Thank you, that solved the problem with menu/tool-bar!


> More likely, your window manager is imposing stringent size requirements
> pursuant to the resize increments Emacs has requested.  
I forgot to mention that I work with KDE Plasma, and I have a specific window rule for Emacs windows, to obey any geometry that they request (see details at end of email*).


While playing with geometries I've noted something else strange. I use desktop-save, so Emacs always restarts with the latest frame & geometry configuration.

However, I'm noticing now that one of the restarted frames always lacks 4 pixels in its vertical scroll bar. I've tried to specify scroll-bar-width in the init.el and early-init.el, but those four pixels disappear at every Emacs restart.

Maybe it's due to my using the lucid theme, rather than GTK...

Cheers,
Luca


* See "Ignore requested geometry" and "Obey geometry restrictions" here:

https://docs.kde.org/stable5/en/kwin/kcontrol/windowspecific/attributes.html

Re: 4 pixels missing at startup

[Po Lu]

PierGianLuca <luca@magnaspesmeretrix.org> writes:

> I forgot to mention that I work with KDE Plasma, and I have a specific
> window rule for Emacs windows, to obey any geometry that they request
> (see details at end of email*).
>
>
> While playing with geometries I've noted something else strange. I use
> desktop-save, so Emacs always restarts with the latest frame &
> geometry configuration.
>
> However, I'm noticing now that one of the restarted frames always
> lacks 4 pixels in its vertical scroll bar. I've tried to specify
> scroll-bar-width in the init.el and early-init.el, but those four
> pixels disappear at every Emacs restart.
>
> Maybe it's due to my using the lucid theme, rather than GTK...

What about under the no toolkit build?  The X toolkit intrinsics seek to
enforce client-requested size hints independently of the window manager
under certain situations.

In light of various frequently attested difficulties with both the GTK
and Xt family of toolkits, I'm inclined to recommend users build
--with-x-toolkit=none.  Toolkit widgets will be absent from such builds,
but they will work properly under virtually all circumstances that can
be thrown at them; and if they don't, toolkits cannot impede us from
remedying the problems.

Re: 4 pixels missing at startup

[PierGianLuca]

Hi Po, thank you again for very useful feedback!

> What about under the no toolkit build?  The X toolkit intrinsics seek to
> enforce client-requested size hints independently of the window manager
> under certain situations.

Had never tried that (so this is not the same as "lucid", right?), sounds interesting, I'll try it out and report back :)

Cheers,
Luca