bug#37609: Tool-bar-mode grows the frame's height

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

This is a followup to emacs-devel thread with 100% reproducible test case.

On master with any earlier revision before the tabs branch was merged,
and compiled for a Motif or Lucid toolkit, i.e. any build without external
tool-bar, i.e. not GTK builds, (also note that some confusion on emacs-devel
with inconsistent results was caused by not using the required `make clean'
in the lwlib directory after switching toolkits) running

emacs -Q -f tool-bar-mode

that disables tool-bar-mode before it's displayed for the first time,
and evaluating

(let ((initial (assq 'outer-size (frame-geometry))))
  (tool-bar-mode 1)
  (tool-bar-mode 0)
  (list (assq 'outer-size (frame-geometry)) initial))

=> ((outer-size 680 . 693) (outer-size 680 . 676))

indicates growing of the frame's height.

Evaluating the same again produces the correct result:

=> ((outer-size 680 . 693) (outer-size 680 . 693))

OTOH, in a new session again with emacs -Q -f tool-bar-mode

(progn
  (tool-bar-mode 1)
  (assq 'outer-size (frame-geometry)))

=> (outer-size 680 . 693)

(progn
  (tool-bar-mode 0)
  (assq 'outer-size (frame-geometry)))

=> (outer-size 680 . 693)

It's strange that the results are the same because visually
the frame's height grows.  Maybe this is specific to the window manager?
My window manager is MATE.

In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, Motif Version 2.3.8)
 of 2019-10-04 built on localhost
Repository revision: d8e741548cd5221d51536a0cbeabde2e4d925054
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux Mint 19

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Tool-Bar mode disabled

Configured using:
 'configure --with-x-toolkit=motif --enable-checking=yes,glyphs
 --enable-check-lisp-object-type 'CFLAGS=-O0 -g3 -gdwarf-4''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS MOTIF X11 XDBE XIM THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MONETARY: et_EE.UTF-8
  value of $LC_NUMERIC: fi_FI.UTF-8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

 > OTOH, in a new session again with emacs -Q -f tool-bar-mode
[...]
 >    (tool-bar-mode 1)

This changes the outer frame size (also on Windows) which it shouldn't do.
I'll look into it.

martin

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

 >  > OTOH, in a new session again with emacs -Q -f tool-bar-mode
 > [...]
 >  >    (tool-bar-mode 1)
 >
 > This changes the outer frame size (also on Windows) which it shouldn't do.
 > I'll look into it.

As a matter of fact, the behavior you see _is_ the intended one.  On
platforms where Emacs draws the tool bar into the frame (Lucid, Motif,
Windows) it has to (1) first trigger redisplay into drawing the tool
bar at least once so to get its real height and then (2) resize the
frame accordingly so it gets the requested initial number of lines.

This means that with

 > emacs -Q -f tool-bar-mode
 >
 > that disables tool-bar-mode before it's displayed for the first time,

no tool bar gets drawn,

 > and evaluating
 >
 > (let ((initial (assq 'outer-size (frame-geometry))))
 >    (tool-bar-mode 1)

this triggers the resizing of the frame to give it the desired number
of initial lines when a tool bar is present, and

 >    (tool-bar-mode 0)
 >    (list (assq 'outer-size (frame-geometry)) initial))

does _not_ size the frame back because that's the way toggling the
tool bar behaves ever since on the platforms cited above.  The same
holds for the behavior you described as

 > => ((outer-size 680 . 693) (outer-size 680 . 676))
 >
 > indicates growing of the frame's height.
 >
 > Evaluating the same again produces the correct result:
 >
 > => ((outer-size 680 . 693) (outer-size 680 . 693))
 >
 > OTOH, in a new session again with emacs -Q -f tool-bar-mode
 >
 > (progn
 >    (tool-bar-mode 1)
 >    (assq 'outer-size (frame-geometry)))
 >
 > => (outer-size 680 . 693)
 >
 > (progn
 >    (tool-bar-mode 0)
 >    (assq 'outer-size (frame-geometry)))
 >
 > => (outer-size 680 . 693)
 >
 > It's strange that the results are the same because visually
 > the frame's height grows.

The frame grows in both cases to 693 pixels when the tool bar is drawn
for the first time and never resizes afterwards (even when the tool
bar wraps).

We probably could suppress such untimely growing by tricking the code
into believing that the tool bar has already been drawn at least once
even if it was not drawn at all.  But I'm not sure whether such a
change could break runs where showing the tool bar might be delayed
for some reason.  Getting the 'frame-inhibit-implied-resize' stuff
perform sufficiently well was quite tricky.  So is the behavior we see
here annoying enough to warrant such a change?

martin

bug#37609: Tool-bar-mode grows the frame's height

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 5 Oct 2019 20:11:06 +0200
> 
> We probably could suppress such untimely growing by tricking the code
> into believing that the tool bar has already been drawn at least once
> even if it was not drawn at all.  But I'm not sure whether such a
> change could break runs where showing the tool bar might be delayed
> for some reason.  Getting the 'frame-inhibit-implied-resize' stuff
> perform sufficiently well was quite tricky.  So is the behavior we see
> here annoying enough to warrant such a change?

As long as the behavior is consistent on all platforms, as much as
practically possible, I'm okay with this behavior.  But I'm not sure
what was the conclusion regarding Juri's GTK configuration where there
was a different behavior regarding the tab bar.  Was that resolved?

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

>> We probably could suppress such untimely growing by tricking the code
>> into believing that the tool bar has already been drawn at least once
>> even if it was not drawn at all.  But I'm not sure whether such a
>> change could break runs where showing the tool bar might be delayed
>> for some reason.  Getting the 'frame-inhibit-implied-resize' stuff
>> perform sufficiently well was quite tricky.  So is the behavior we see
>> here annoying enough to warrant such a change?
>
> As long as the behavior is consistent on all platforms, as much as
> practically possible, I'm okay with this behavior.  But I'm not sure
> what was the conclusion regarding Juri's GTK configuration where there
> was a different behavior regarding the tab bar.  Was that resolved?

Since there is no such problem on GTK builds that use external tool-bars,
maybe it's ok that this behavior is only on Lucid, Motif, Windows?

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

Revisiting after some recent changes:

 > emacs -Q -f tool-bar-mode
 >
 > that disables tool-bar-mode before it's displayed for the first time,
 > and evaluating
 >
 > (let ((initial (assq 'outer-size (frame-geometry))))
 >    (tool-bar-mode 1)
 >    (tool-bar-mode 0)
 >    (list (assq 'outer-size (frame-geometry)) initial))
 >
 > => ((outer-size 680 . 693) (outer-size 680 . 676))
 >
 > indicates growing of the frame's height.

Here I get with a current Lucid (I suppose you will encounter troubles
building with Motif these days) build

((outer-size 764 . 702) (outer-size 764 . 702))

whereas on Emacs 27 this was indeed

((outer-size 764 . 720) (outer-size 764 . 702))

Can you please check again?

 > OTOH, in a new session again with emacs -Q -f tool-bar-mode
 >
 > (progn
 >    (tool-bar-mode 1)
 >    (assq 'outer-size (frame-geometry)))
 >
 > => (outer-size 680 . 693)

This gets me

(outer-size 764 . 720)

but evaluating

(assq 'outer-size (frame-geometry))

once more (it takes time to relate such changes to `frame-geometry') now
gives

(outer-size 764 . 738)

which should yield the same value of (frame-height) as before (please
check).  On Emacs 27 this was botched because the outer size changed to

(outer-size 764 . 720)

only and the frame height dropped from 36 to 35 lines.

 > (progn
 >    (tool-bar-mode 0)
 >    (assq 'outer-size (frame-geometry)))
 >
 > => (outer-size 680 . 693)

This now gets me

(outer-size 764 . 702)

as expected.

 > It's strange that the results are the same because visually
 > the frame's height grows.

So please have one more look into this issue.

Thanks, martin

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

> Revisiting after some recent changes:
>
>> emacs -Q -f tool-bar-mode
>>
>> that disables tool-bar-mode before it's displayed for the first time,
>> and evaluating
>>
>> (let ((initial (assq 'outer-size (frame-geometry))))
>>    (tool-bar-mode 1)
>>    (tool-bar-mode 0)
>>    (list (assq 'outer-size (frame-geometry)) initial))
>>
>> => ((outer-size 680 . 693) (outer-size 680 . 676))
>>
>> indicates growing of the frame's height.
>
> Here I get with a current Lucid (I suppose you will encounter troubles
> building with Motif these days) build
>
> ((outer-size 764 . 702) (outer-size 764 . 702))
>
> whereas on Emacs 27 this was indeed
>
> ((outer-size 764 . 720) (outer-size 764 . 702))
>
> Can you please check again?

Now the frame's height doesn't grow but shrinks on GTK:

((outer-size 694 . 690) (outer-size 694 . 738))

>> OTOH, in a new session again with emacs -Q -f tool-bar-mode
>>
>> (progn
>>    (tool-bar-mode 1)
>>    (assq 'outer-size (frame-geometry)))
>>
>> => (outer-size 680 . 693)
>
> This gets me
>
> (outer-size 764 . 720)

(outer-size 694 . 690)

> but evaluating
>
> (assq 'outer-size (frame-geometry))
>
> once more (it takes time to relate such changes to `frame-geometry') now
> gives
>
> (outer-size 764 . 738)

(outer-size 694 . 738)

> which should yield the same value of (frame-height) as before (please
> check).

(frame-height)
36

> On Emacs 27 this was botched because the outer size changed to
>
> (outer-size 764 . 720)
>
> only and the frame height dropped from 36 to 35 lines.
>
>> (progn
>>    (tool-bar-mode 0)
>>    (assq 'outer-size (frame-geometry)))
>>
>> => (outer-size 680 . 693)
>
> This now gets me
>
> (outer-size 764 . 702)
>
> as expected.

(outer-size 694 . 690)

>> It's strange that the results are the same because visually
>> the frame's height grows.

> So please have one more look into this issue.

Do you think now it's improved?

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

 >> Can you please check again?

Did you check with Lucid?

 > Now the frame's height doesn't grow but shrinks on GTK:
 >
 > ((outer-size 694 . 690) (outer-size 694 . 738))

Here when I start a GTK3 build with

emacs -Q -f tool-bar-mode

and do

(let ((initial (assq 'outer-size (frame-geometry))))
   (tool-bar-mode 1)
   (tool-bar-mode 0)
   (list (assq 'outer-size (frame-geometry)) initial))

I get

((outer-size 762 . 697) (outer-size 762 . 697))

an invariable frame height of 36, a frame pixel height of 648 (which
sums up correctly with a menu bar height of 25, a title bar height of 14
and an external border of 5 pixels) and no visible change of any kind.

 >>> OTOH, in a new session again with emacs -Q -f tool-bar-mode
 >>>
 >>> (progn
 >>>     (tool-bar-mode 1)
 >>>     (assq 'outer-size (frame-geometry)))
 >>>
 >>> => (outer-size 680 . 693)
 >>
 >> This gets me
 >>
 >> (outer-size 764 . 720)
 >
 > (outer-size 694 . 690)
 >
 >> but evaluating
 >>
 >> (assq 'outer-size (frame-geometry))
 >>
 >> once more (it takes time to relate such changes to `frame-geometry') now
 >> gives
 >>
 >> (outer-size 764 . 738)
 >
 > (outer-size 694 . 738)
 >
 >> which should yield the same value of (frame-height) as before (please
 >> check).
 >
 > (frame-height)
 > 36
 >
 >> On Emacs 27 this was botched because the outer size changed to
 >>
 >> (outer-size 764 . 720)
 >>
 >> only and the frame height dropped from 36 to 35 lines.
 >>
 >>> (progn
 >>>     (tool-bar-mode 0)
 >>>     (assq 'outer-size (frame-geometry)))
 >>>
 >>> => (outer-size 680 . 693)
 >>
 >> This now gets me
 >>
 >> (outer-size 764 . 702)
 >>
 >> as expected.
 >
 > (outer-size 694 . 690)
 >
 >>> It's strange that the results are the same because visually
 >>> the frame's height grows.
 >
 >> So please have one more look into this issue.
 >
 > Do you think now it's improved?

It's up to you to decide.  I can try to fix all inconsistencies you
still see.

As far as outer sizes are concerned be aware that snippets like

(progn
   (tool-bar-mode 1)
   (assq 'outer-size (frame-geometry)))

might not tell the whole truth because the frame geometry may not have
changed yet at the time you call that function.  And please make sure
to associate every result you report with the corresponding toolkit.

Thanks, martin

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

>>> Can you please check again?
>
> Did you check with Lucid?

In Lucid

((outer-size 696 . 706) (outer-size 696 . 706))

>> Now the frame's height doesn't grow but shrinks on GTK:
>>
>> ((outer-size 694 . 690) (outer-size 694 . 738))
>
> Here when I start a GTK3 build with
>
> emacs -Q -f tool-bar-mode
>
> and do
>
> (let ((initial (assq 'outer-size (frame-geometry))))
>   (tool-bar-mode 1)
>   (tool-bar-mode 0)
>   (list (assq 'outer-size (frame-geometry)) initial))
>
> I get
>
> ((outer-size 762 . 697) (outer-size 762 . 697))
>
> an invariable frame height of 36, a frame pixel height of 648 (which
> sums up correctly with a menu bar height of 25, a title bar height of 14
> and an external border of 5 pixels) and no visible change of any kind.

I get in a GTK3 build

((outer-size 694 . 690) (outer-size 694 . 690))

(frame-height)
36

>> Do you think now it's improved?
>
> It's up to you to decide.  I can try to fix all inconsistencies you
> still see.

Thanks.

> As far as outer sizes are concerned be aware that snippets like
>
> (progn
>   (tool-bar-mode 1)
>   (assq 'outer-size (frame-geometry)))
>
> might not tell the whole truth because the frame geometry may not have
> changed yet at the time you call that function.  And please make sure
> to associate every result you report with the corresponding toolkit.

Noted 👍.

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

 > In Lucid
 >
 > ((outer-size 696 . 706) (outer-size 696 . 706))

These look good now.  To check once more: What do

(frame-height)
(frame-char-height)
(frame-pixel-height)

give for that frame?

 > I get in a GTK3 build
 >
 > ((outer-size 694 . 690) (outer-size 694 . 690))
 >
 > (frame-height)
 > 36

And again what are the values reported by

(frame-char-height)
(frame-pixel-height)

here?

martin

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

>> In Lucid
>>
>> ((outer-size 696 . 706) (outer-size 696 . 706))
>
> These look good now.  To check once more: What do
>
> (frame-height)
> (frame-char-height)
> (frame-pixel-height)

In Lucid

(frame-height)
38
(frame-char-height)
17
(frame-pixel-height)
648

>> I get in a GTK3 build
>>
>> ((outer-size 694 . 690) (outer-size 694 . 690))
>>
>> (frame-height)
>> 36
>
> And again what are the values reported by
>
> (frame-char-height)
> (frame-pixel-height)

In GTK3

(frame-height)
36
(frame-char-height)
17
(frame-pixel-height)
612

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

 > In Lucid
 >
 > (frame-height)
 > 38

This should be 36 and is 36 here.  What does (frame-height) give right
after you started Emacs with

emacs -Q -f tool-bar-mode

and before you do

(let ((initial (assq 'outer-size (frame-geometry))))
   (tool-bar-mode 1)
   (tool-bar-mode 0)
   (list (assq 'outer-size (frame-geometry)) initial))

 > In GTK3
 >
 > (frame-height)
 > 36

This is OK.

martin

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

>> In Lucid
>>
>> (frame-height)
>> 38
>
> This should be 36 and is 36 here.  What does (frame-height) give right
> after you started Emacs with
>
> emacs -Q -f tool-bar-mode
>
> and before you do
>
> (let ((initial (assq 'outer-size (frame-geometry))))
>   (tool-bar-mode 1)
>   (tool-bar-mode 0)
>   (list (assq 'outer-size (frame-geometry)) initial))

Sorry for the mess.  Actually, in Lucid emacs -Q -f tool-bar-mode:

(frame-height)
36

(let ((initial (assq 'outer-size (frame-geometry))))
  (tool-bar-mode 1)
  (tool-bar-mode 0)
  (list (assq 'outer-size (frame-geometry)) initial))
((outer-size 696 . 687) (outer-size 696 . 687))

(frame-height)
36

bug#37609: Tool-bar-mode grows the frame's height

[martin rudalics]

 > Sorry for the mess.  Actually, in Lucid emacs -Q -f tool-bar-mode:
 >
 > (frame-height)
 > 36
 >
 > (let ((initial (assq 'outer-size (frame-geometry))))
 >    (tool-bar-mode 1)
 >    (tool-bar-mode 0)
 >    (list (assq 'outer-size (frame-geometry)) initial))
 > ((outer-size 696 . 687) (outer-size 696 . 687))
 >
 > (frame-height)
 > 36

That's better.

martin

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

>> (frame-height)
>> 36
>
> That's better.

So now this report is closed.

bug#37609: Tool-bar-mode grows the frame's height

[Juri Linkov]

>> We probably could suppress such untimely growing by tricking the code
>> into believing that the tool bar has already been drawn at least once
>> even if it was not drawn at all.  But I'm not sure whether such a
>> change could break runs where showing the tool bar might be delayed
>> for some reason.  Getting the 'frame-inhibit-implied-resize' stuff
>> perform sufficiently well was quite tricky.  So is the behavior we see
>> here annoying enough to warrant such a change?
>
> I now did the above described in order to fix Bug#52986 on master.
> Please have a look whether anything got broken.

Thanks, it seems nothing's broken.