unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>, 37609@debbugs.gnu.org
Subject: bug#37609: Tool-bar-mode grows the frame's height
Date: Sat, 5 Oct 2019 20:11:06 +0200	[thread overview]
Message-ID: <cc1b01aa-a59b-4128-6b0b-61f817ceb90a@gmx.at> (raw)
In-Reply-To: <c300a3ff-a7fd-e64a-5258-217d6734028c@gmx.at>

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





  reply	other threads:[~2019-10-05 18:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03 22:20 bug#37609: Tool-bar-mode grows the frame's height Juri Linkov
2019-10-05  8:41 ` martin rudalics
2019-10-05 18:11   ` martin rudalics [this message]
2019-10-05 19:04     ` Eli Zaretskii
2019-10-05 22:44       ` Juri Linkov
     [not found]     ` <626bf59c-99e7-b6ac-5e0e-7493d214d4e2@gmx.at>
2022-01-24 18:03       ` Juri Linkov
2021-05-04  9:15 ` martin rudalics
2021-05-04 21:42   ` Juri Linkov
2021-05-05  7:24     ` martin rudalics
2021-05-05 20:37       ` Juri Linkov
2021-05-06  7:45         ` martin rudalics
2021-05-07 16:50           ` Juri Linkov
2021-05-08  7:16             ` martin rudalics
2021-05-08 20:23               ` Juri Linkov
2021-05-09  8:41                 ` martin rudalics
2021-05-09 17:43                   ` Juri Linkov

Reply instructions:

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

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

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

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

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

  git send-email \
    --in-reply-to=cc1b01aa-a59b-4128-6b0b-61f817ceb90a@gmx.at \
    --to=rudalics@gmx.at \
    --cc=37609@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /path/to/YOUR_REPLY

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

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

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

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