unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#37609: Tool-bar-mode grows the frame's height
@ 2019-10-03 22:20 Juri Linkov
  2019-10-05  8:41 ` martin rudalics
  2021-05-04  9:15 ` martin rudalics
  0 siblings, 2 replies; 10+ messages in thread
From: Juri Linkov @ 2019-10-03 22:20 UTC (permalink / raw)
  To: 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  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
  2021-05-04  9:15 ` martin rudalics
  1 sibling, 1 reply; 10+ messages in thread
From: martin rudalics @ 2019-10-05  8:41 UTC (permalink / raw)
  To: Juri Linkov, 37609

 > 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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2019-10-05  8:41 ` martin rudalics
@ 2019-10-05 18:11   ` martin rudalics
  2019-10-05 19:04     ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: martin rudalics @ 2019-10-05 18:11 UTC (permalink / raw)
  To: Juri Linkov, 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2019-10-05 18:11   ` martin rudalics
@ 2019-10-05 19:04     ` Eli Zaretskii
  2019-10-05 22:44       ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2019-10-05 19:04 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37609, juri

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2019-10-05 19:04     ` Eli Zaretskii
@ 2019-10-05 22:44       ` Juri Linkov
  0 siblings, 0 replies; 10+ messages in thread
From: Juri Linkov @ 2019-10-05 22:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2019-10-03 22:20 bug#37609: Tool-bar-mode grows the frame's height Juri Linkov
  2019-10-05  8:41 ` martin rudalics
@ 2021-05-04  9:15 ` martin rudalics
  2021-05-04 21:42   ` Juri Linkov
  1 sibling, 1 reply; 10+ messages in thread
From: martin rudalics @ 2021-05-04  9:15 UTC (permalink / raw)
  To: Juri Linkov, 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2021-05-04  9:15 ` martin rudalics
@ 2021-05-04 21:42   ` Juri Linkov
  2021-05-05  7:24     ` martin rudalics
  0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2021-05-04 21:42 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2021-05-04 21:42   ` Juri Linkov
@ 2021-05-05  7:24     ` martin rudalics
  2021-05-05 20:37       ` Juri Linkov
  0 siblings, 1 reply; 10+ messages in thread
From: martin rudalics @ 2021-05-05  7:24 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2021-05-05  7:24     ` martin rudalics
@ 2021-05-05 20:37       ` Juri Linkov
  2021-05-06  7:45         ` martin rudalics
  0 siblings, 1 reply; 10+ messages in thread
From: Juri Linkov @ 2021-05-05 20:37 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37609

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





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#37609: Tool-bar-mode grows the frame's height
  2021-05-05 20:37       ` Juri Linkov
@ 2021-05-06  7:45         ` martin rudalics
  0 siblings, 0 replies; 10+ messages in thread
From: martin rudalics @ 2021-05-06  7:45 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 37609

 > 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





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-05-06  7:45 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-10-05 19:04     ` Eli Zaretskii
2019-10-05 22:44       ` 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

unofficial mirror of bug-gnu-emacs@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/emacs-bugs/0 emacs-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 emacs-bugs emacs-bugs/ https://yhetil.org/emacs-bugs \
		bug-gnu-emacs@gnu.org
	public-inbox-index emacs-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.bugs
	nntp://news.gmane.io/gmane.emacs.bugs


code repositories for project(s) associated with this inbox:

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

AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git