GNU bug report logs - #42957
28.0.50; Tool bar button click doesn't update the tool bar immediately

Previous Next

Package: emacs;

Reported by: Mauro Aranda <maurooaranda <at> gmail.com>

Date: Thu, 20 Aug 2020 14:53:01 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42957 in the body.
You can then email your comments to 42957 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#42957; Package emacs. (Thu, 20 Aug 2020 14:53:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mauro Aranda <maurooaranda <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 20 Aug 2020 14:53:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 28.0.50; Tool bar button click doesn't update the tool bar immediately
Date: Thu, 20 Aug 2020 11:52:04 -0300
[Message part 1 (text/plain, inline)]
Consider the following:
1. emacs -Q
2. In the scratch buffer, evaluate the following:
(defvar foo t)

(defun set-foo-to-nil ()
  "Set `foo' to nil."
  (interactive)
  (setq foo nil))

(tool-bar-add-item "refresh" 'set-foo-to-nil nil :enable 'foo
  :label "foo-refresh")

3. Do some clicks or whatever, so that the item foo-refresh appears (I
guess this is bug#19480).
4. Now click the foo-refresh button.  I expected the button to get
disabled immediately, but that doesn't happen.
5. Click in the buffer, and the button will be disabled.

Could Emacs update the tool bar immediately when the user clicks on a
tool bar button? Or am I forced (no pun intended) to use
`force-mode-line-update' in the commands that may alter the
enable/disable state of the tool bar buttons, even when the commands
run because of a tool bar button click?


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30,
cairo version 1.15.10)
 of 2020-08-20 built on tbb-desktop
Repository revision: a566e409d0d962d3c2870691175836da22c31111
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 18.04.5 LTS

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE
XIM MODULES THREADS PDUMPER

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search seq byte-opt gv
bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x cl-loaddefs
cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 44547 5333)
 (symbols 48 5963 1)
 (strings 32 15413 1637)
 (string-bytes 1 503972)
 (vectors 16 9833)
 (vector-slots 8 144854 10085)
 (floats 8 21 45)
 (intervals 56 224 4)
 (buffers 992 11))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42957; Package emacs. (Fri, 16 Oct 2020 09:11:02 GMT) Full text and rfc822 format available.

Message #8 received at 42957 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 42957 <at> debbugs.gnu.org
Subject: Re: bug#42957: 28.0.50; Tool bar button click doesn't update the
 tool bar immediately
Date: Fri, 16 Oct 2020 11:10:24 +0200
Mauro Aranda <maurooaranda <at> gmail.com> writes:

> 4. Now click the foo-refresh button.  I expected the button to get
> disabled immediately, but that doesn't happen.
> 5. Click in the buffer, and the button will be disabled.

Yup; this problem is still present on the trunk.

> Could Emacs update the tool bar immediately when the user clicks on a
> tool bar button? Or am I forced (no pun intended) to use
> `force-mode-line-update' in the commands that may alter the
> enable/disable state of the tool bar buttons, even when the commands
> run because of a tool bar button click?

I don't know, but if Emacs can't do that, then this should be
documented, at least.  This is documented in other context, like:

--
  The menu bar does not recalculate which items are enabled every time you
look at a menu.  This is because the X toolkit requires the whole tree
of menus in advance.  To force recalculation of the menu bar, call
@code{force-mode-line-update} (@pxref{Mode Line Format}).
--

But not in the tool bar sections, as far as I can see.  But I guess if
the menu bar doesn't update automatically on enabling, then it would
perhaps be surprising that tool bars do.

So I think we should just document this quirk?  Any opinions?

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42957; Package emacs. (Sun, 13 Dec 2020 13:57:01 GMT) Full text and rfc822 format available.

Message #11 received at 42957 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 42957 <at> debbugs.gnu.org
Subject: Re: bug#42957: 28.0.50; Tool bar button click doesn't update the
 tool bar immediately
Date: Sun, 13 Dec 2020 10:56:39 -0300
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> 4. Now click the foo-refresh button.  I expected the button to get
>> disabled immediately, but that doesn't happen.
>> 5. Click in the buffer, and the button will be disabled.
>
> Yup; this problem is still present on the trunk.
>
>> Could Emacs update the tool bar immediately when the user clicks on a
>> tool bar button? Or am I forced (no pun intended) to use
>> `force-mode-line-update' in the commands that may alter the
>> enable/disable state of the tool bar buttons, even when the commands
>> run because of a tool bar button click?
>
> I don't know, but if Emacs can't do that, then this should be
> documented, at least.  This is documented in other context, like:
>
> --
>   The menu bar does not recalculate which items are enabled every time you
> look at a menu.  This is because the X toolkit requires the whole tree
> of menus in advance.  To force recalculation of the menu bar, call
> @code{force-mode-line-update} (@pxref{Mode Line Format}).
> --
>
> But not in the tool bar sections, as far as I can see.  But I guess if
> the menu bar doesn't update automatically on enabling, then it would
> perhaps be surprising that tool bars do.
>
> So I think we should just document this quirk?  Any opinions?

Hi Lars,

Thanks for taking a look, and sorry it took me so long to reply back.

If it can't be done easily, I'm fine with closing this report as a
wontfix.  It doesn't annoy me too much to put some
force-mode-line-update calls here and there.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#42957; Package emacs. (Mon, 14 Dec 2020 16:09:01 GMT) Full text and rfc822 format available.

Message #14 received at 42957 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 42957 <at> debbugs.gnu.org
Subject: Re: bug#42957: 28.0.50; Tool bar button click doesn't update the
 tool bar immediately
Date: Mon, 14 Dec 2020 17:08:14 +0100
Mauro Aranda <maurooaranda <at> gmail.com> writes:

> Thanks for taking a look, and sorry it took me so long to reply back.
>
> If it can't be done easily, I'm fine with closing this report as a
> wontfix.  It doesn't annoy me too much to put some
> force-mode-line-update calls here and there.

I've now mentioned this quirk in the Tool Bar node in the manual, so I'm
closing this bug report.

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




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 14 Dec 2020 16:09:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 42957 <at> debbugs.gnu.org and Mauro Aranda <maurooaranda <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 14 Dec 2020 16:09:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 12 Jan 2021 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 76 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.