bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Richard Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 4665 bytes --]

emacs -Q
M-: (setq auto-resize-tool-bars 'grow-only) RET
C-s

The tool bar now shows a ridiculously oversized marine life ring icon on the "Help" button, and the height of the tool bar has grown to accommodate the icon's size.

C-g

Expected behavior: The tool bar reverts back to how it was before C-s was pressed, except its height stays the same.

Actual behavior: The tool bar reverts back to how it was before, including reverting to its original height.

The continually changing tool bar height causes the windows under the toolbar to "bounce".  This is particularly annoying when a mouse click causes the tool bar to change height because Emacs interprets the click as a drag event (even though the mouse cursor has not moved).



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
  of 2022-07-13 built on lcy02-amd64-070
System Description: Ubuntu 20.04.4 LTS

Configured using:
  'configure --build=x86_64-linux-gnu --prefix=/usr
  '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
  '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
  --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'
  '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
  --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
  --program-suffix=-snapshot --with-modules=yes --with-x=yes
  --with-x-toolkit=gtk3 --with-xwidgets=yes --with-pgtk=yes 'CFLAGS=-g
  -O2
  -fdebug-prefix-map=/build/emacs-snapshot-vc8IGV/emacs-snapshot-107401=. -fstack-protector-strong
  -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time
  -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB

Important settings:
   value of $LC_MONETARY: en_US.UTF-8
   value of $LC_NUMERIC: en_US.UTF-8
   value of $LC_TIME: root.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch cl-extra cl-print byte-opt gv bytecomp
byte-compile cconv thingatpt help-fns radix-tree help-mode cl-loaddefs
cl-lib rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 50267 10716)
  (symbols 48 6002 0)
  (strings 32 18737 2250)
  (string-bytes 1 550849)
  (vectors 16 11492)
  (vector-slots 8 165468 12321)
  (floats 8 29 22)
  (intervals 56 274 0)
  (buffers 992 12))

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

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

Richard Hansen <rhansen@rhansen.org> writes:

> emacs -Q
> M-: (setq auto-resize-tool-bars 'grow-only) RET
> C-s
>
> The tool bar now shows a ridiculously oversized marine life ring icon
> on the "Help" button, and the height of the tool bar has grown to
> accommodate the icon's size.
>
> C-g
>
> Expected behavior: The tool bar reverts back to how it was before C-s
> was pressed, except its height stays the same.
>
> Actual behavior: The tool bar reverts back to how it was before,
> including reverting to its original height.
>
> The continually changing tool bar height causes the windows under the
> toolbar to "bounce".  This is particularly annoying when a mouse click
> causes the tool bar to change height because Emacs interprets the
> click as a drag event (even though the mouse cursor has not moved).

`auto-resize-tool-bars' doesn't work with either of the GTK builds,
since tool bars there don't wrap at all, and their dimensions are not
under the control of Emacs.

So the solution is to stop setting that variable.

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Eli Zaretskii]

> Date: Sat, 16 Jul 2022 21:52:09 -0400
> From: Richard Hansen <rhansen@rhansen.org>
> 
> emacs -Q
> M-: (setq auto-resize-tool-bars 'grow-only) RET
> C-s
> 
> The tool bar now shows a ridiculously oversized marine life ring icon on the "Help" button, and the height of the tool bar has grown to accommodate the icon's size.
> 
> C-g
> 
> Expected behavior: The tool bar reverts back to how it was before C-s was pressed, except its height stays the same.
> 
> Actual behavior: The tool bar reverts back to how it was before, including reverting to its original height.

I cannot reproduce this because on my system the Help button doesn't
get the "ridiculously oversized marine life ring icon", so the tool
bar doesn't resize.  But I see something suspicious in the code which
handles this feature:

  if (!NILP (Vauto_resize_tool_bars))
    {
      bool change_height_p = true;  <<<<<<<<<<<<<<<<<<<<<<

AFAIU, that initialization should have been to 'false', not 'true'.
Can you try this on your system and see if such a change gives good
results?

Thanks.

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Eli Zaretskii]

> Cc: 56607@debbugs.gnu.org
> Date: Sun, 17 Jul 2022 08:57:37 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 16 Jul 2022 21:52:09 -0400
> > From: Richard Hansen <rhansen@rhansen.org>
> > 
> > emacs -Q
> > M-: (setq auto-resize-tool-bars 'grow-only) RET
> > C-s
> > 
> > The tool bar now shows a ridiculously oversized marine life ring icon on the "Help" button, and the height of the tool bar has grown to accommodate the icon's size.
> > 
> > C-g
> > 
> > Expected behavior: The tool bar reverts back to how it was before C-s was pressed, except its height stays the same.
> > 
> > Actual behavior: The tool bar reverts back to how it was before, including reverting to its original height.
> 
> I cannot reproduce this because on my system the Help button doesn't
> get the "ridiculously oversized marine life ring icon", so the tool
> bar doesn't resize.

FWIW, the basic functionality in the display engine does work.  I can
simulate the resizing of the tool bar with the following snippet:

  (setq old-map (copy-sequence tool-bar-map))
  (tool-bar-add-item-from-menu 'dired "splash")

If I then evaluate the below:

  (setq tool-bar-map (copy-sequence old-map))

the large icon disappears, and under auto-resize-tool-bars set to
grow-only the tool bar stays the same dimensions.

So if the tool bar is displayed by Emacs (as opposed to by a toolkit),
the auto-resizing works as expected.  I guess this is indeed a GTK
thing, since it doesn't heed our variables?

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Richard Hansen]

[-- Attachment #1.1.1: Type: text/plain, Size: 1382 bytes --]

Eli Zaretskii wrote:
> But I see something suspicious in the code which handles this 
> feature:
> 
>    if (!NILP (Vauto_resize_tool_bars))
>      {
>        bool change_height_p = true;  <<<<<<<<<<<<<<<<<<<<<<
> 
> AFAIU, that initialization should have been to 'false', not 'true'.

Yes, I think you are correct.  The nearly identical code in redisplay_tab_bar has the same problem.

> Can you try this on your system and see if such a change gives good
> results?

Unfortunately, changing it to false had no effect.  gdb didn't find the redisplay_tool_bar symbol, so pgtk builds must define HAVE_EXT_TOOL_BAR.

Lars Ingebrigtsen wrote:
>> The tool bar now shows a ridiculously oversized marine life ring icon 
>> on the "Help" button, and the height of the tool bar has grown to 
>> accommodate the icon's size.
> 
> That sounds like a bug in itself -- I'm not seeing any marine life ring 
> icons at all with --with-pgtk, so I wonder where that is coming from. 
> Do you have a screenshot?

Attached is an animated gif showing the icon and bounce effect.

Po Lu wrote:
> `auto-resize-tool-bars' doesn't work with either of the GTK builds, 
> since tool bars there don't wrap at all, and their dimensions are not 
> under the control of Emacs.

Can the toolbar be nested inside a container widget whose size we can control?

Thanks,
Richard

[-- Attachment #1.1.2: animation.gif --]
[-- Type: image/gif, Size: 39651 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

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

Richard Hansen <rhansen@rhansen.org> writes:

> Can the toolbar be nested inside a container widget whose size we can
> control?

Perhaps, but then we would only be controlling the size of that widget,
and not the toolbar itself.

GTK toolbars don't wrap extra items, they truncate them.  So
`auto-resize-tool-bars' has no real chance of working anyway.

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Richard Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 1057 bytes --]

Po Lu wrote:
> Richard Hansen <rhansen@rhansen.org> writes:
> 
>> Can the toolbar be nested inside a container widget whose size we can 
>> control?
> 
> Perhaps, but then we would only be controlling the size of that widget, 
> and not the toolbar itself.

Can the dimensions of the toolbar be inspected?  If so, we can force the container widget to never shrink if `auto-resize-tool-bars' is `grow-only'.

> 
> GTK toolbars don't wrap extra items, they truncate them.  So 
> `auto-resize-tool-bars' has no real chance of working anyway.

If the toolbar width changes, we could do the (un)wrapping ourselves: move the buttons to/from another toolbar underneath the upper toolbar.  The lower toolbar would still be inside the same container widget as the upper toolbar, and `grow-only' would pay attention to the sum of the heights of the toolbars.  Would that work?

(Sorry for all of the questions; I'm not familiar with GTK.  But I'm willing to spend some time to cook up some patches if given some hints on how to tackle the problem.)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

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

Richard Hansen <rhansen@rhansen.org> writes:

> Can the dimensions of the toolbar be inspected?

Yes, the height and width are constant when the tool bar is on the top
or bottom.  When the tool bar is on the left or right of the frame, then
resizing can happen, but in that case I'm not sure how it works.

> If so, we can force the container widget to never shrink if
> `auto-resize-tool-bars' is `grow-only'.

GTK never resizes the tool bar itself, so I'm not sure how that would
make a difference.

> If the toolbar width changes, we could do the (un)wrapping ourselves:
> move the buttons to/from another toolbar underneath the upper toolbar.
> The lower toolbar would still be inside the same container widget as
> the upper toolbar, and `grow-only' would pay attention to the sum of
> the heights of the toolbars.  Would that work?

Maybe, but it's a lot of trouble to create such a feature that the GTK
developers are bound to break at some point.

> (Sorry for all of the questions; I'm not familiar with GTK.  But I'm
> willing to spend some time to cook up some patches if given some hints
> on how to tackle the problem.)

I'd rather just disable auto-resize-tool-bars under GTK.  That's not a
feature GTK tool bars are designed to support.

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Richard Hansen]

[-- Attachment #1.1: Type: text/plain, Size: 1974 bytes --]

On 7/18/22 00:35, Po Lu wrote:
> Richard Hansen <rhansen@rhansen.org> writes:
> 
>> Can the dimensions of the toolbar be inspected?
> 
> Yes, the height and width are constant when the tool bar is on the top
> or bottom.  When the tool bar is on the left or right of the frame, then
> resizing can happen, but in that case I'm not sure how it works.
> 
>> If so, we can force the container widget to never shrink if
>> `auto-resize-tool-bars' is `grow-only'.
> 
> GTK never resizes the tool bar itself, so I'm not sure how that would
> make a difference.

What I mean is we would inspect the size of the toolbar (before any clipping required to fit inside the container widget) then adjust the size of the container widget appropriately.

> 
>> If the toolbar width changes, we could do the (un)wrapping ourselves: 
>> move the buttons to/from another toolbar underneath the upper toolbar. 
>> The lower toolbar would still be inside the same container widget as 
>> the upper toolbar, and `grow-only' would pay attention to the sum of 
>> the heights of the toolbars.  Would that work?
> 
> Maybe, but it's a lot of trouble to create such a feature that the GTK 
> developers are bound to break at some point.

That's a good point.  Out of curiosity I looked into GTK4 and they did away with the toolbar class.  Users should instead use a GtkBox containing buttons, and apply appropriate styling.  libadwaita provides a toolbar style class for this purpose [1].  I'm guessing it would be straightforward to implement toolbar button wrapping in GTK4, if/when Emacs migrates to it.

[1] https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/style-classes.html#toolbars

> 
> I'd rather just disable auto-resize-tool-bars under GTK.  That's not a 
> feature GTK tool bars are designed to support.

Fair enough.  In the meantime I filed bug#56627 about the inconsistent toolbar button icon sizing.  Maybe that issue is easier to fix.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

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

Richard Hansen <rhansen@rhansen.org> writes:

> What I mean is we would inspect the size of the toolbar (before any
> clipping required to fit inside the container widget) then adjust the
> size of the container widget appropriately.

I'm not sure what you're talking about.  What is being clipped to fit
inside the container widget?

> That's a good point.  Out of curiosity I looked into GTK4 and they did
> away with the toolbar class.  Users should instead use a GtkBox
> containing buttons, and apply appropriate styling.  libadwaita
> provides a toolbar style class for this purpose [1].  I'm guessing it
> would be straightforward to implement toolbar button wrapping in GTK4,
> if/when Emacs migrates to it.

It will be more straightforward to implement tool-bar wrapping.

But I gave up on the GTK 4 work I was doing, since GTK 4 is simply not
ready: it doesn't even support subpixel anti-aliasing, and has many
regressions compared to GTK 3 when it comes to display synchronization,
drag-and-drop, and selections.

bug#56607: 29.0.50; (setq auto-resize-tool-bars 'grow-only) has no effect (pgtk)

[Lars Ingebrigtsen]

Richard Hansen <rhansen@rhansen.org> writes:

> The tool bar now shows a ridiculously oversized marine life ring icon
> on the "Help" button, and the height of the tool bar has grown to
> accommodate the icon's size.

That sounds like a bug in itself -- I'm not seeing any marine life ring
icons at all with --with-pgtk, so I wonder where that is coming from.
Do you have a screenshot?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no