GNU bug report logs - #75844
Update for window-tool-bar

Previous Next

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

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

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

From: Jared Finder <jared <at> finder.org>
To: Bug-gnu Emacs <bug-gnu-emacs <at> gnu.org>
Subject: Update for window-tool-bar
Date: Sat, 25 Jan 2025 14:38:51 -0800

[Message part 1 (text/plain, inline)]

Attached is a patch to window-tool-bar. This adds support for the rest 
of the tool bar item specifiers.  I have been running with this locally 
for a couple of months to ensure it had no major performance regressions 
because it does add more code run per tool bar item refresh.

Separately, I also have an example tool bar mode that I use alongside 
developing the window-tool-bar.  This example shows off the capabilities 
of tool bars.  At the moment, it is limited to just what window-tool-bar 
supports.  I'd be happy to add that as well to Emacs for any further 
tool bar development in general.

  -- MJF

[0001-Update-window-tool-bar.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>, martin rudalics <rudalics <at> gmx.at>
Cc: 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Sat, 01 Feb 2025 13:02:55 +0200

> Date: Sat, 25 Jan 2025 14:38:51 -0800
> From:  Jared Finder via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Attached is a patch to window-tool-bar. This adds support for the rest 
> of the tool bar item specifiers.  I have been running with this locally 
> for a couple of months to ensure it had no major performance regressions 
> because it does add more code run per tool bar item refresh.

Thanks.  Martin, any comments?

I see you use :package-version, but doing so should also update
customize-package-emacs-version-alist, AFAIU.  Any reasons why you
didn't?

> Separately, I also have an example tool bar mode that I use alongside 
> developing the window-tool-bar.  This example shows off the capabilities 
> of tool bars.  At the moment, it is limited to just what window-tool-bar 
> supports.  I'd be happy to add that as well to Emacs for any further 
> tool bar development in general.

Sorry, I don't understand what does "example tool bar mode" mean.  Can
you elaborate what would be the use of that in Emacs?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Jared Finder <jared <at> finder.org>
Cc: 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Sun, 2 Feb 2025 09:52:34 +0100

> Thanks.  Martin, any comments?

Just the obvious: "The meanining is ..." should be fixed and "can not"
should become "cannot".

BTW this

;; Dragging empty space on the tab-line (which this package uses to
;; display the window tool bar) doesn't resize windows.  This is
;; unlike the mode line, where dragging empty space resizes the
;; window.

apparently hasn't been fixed.  Why not?

martin

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

From: Jared Finder <jared <at> finder.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Sun, 02 Feb 2025 13:17:01 -0800

On 2025-02-02 00:52, martin rudalics wrote:
>> Thanks.  Martin, any comments?
> 
> Just the obvious: "The meanining is ..." should be fixed and "can not"
> should become "cannot".

Thanks. Typos fixed and I added a mapping to 
customize-package-emacs-version-alist.

> BTW this
> 
> ;; Dragging empty space on the tab-line (which this package uses to
> ;; display the window tool bar) doesn't resize windows.  This is
> ;; unlike the mode line, where dragging empty space resizes the
> ;; window.
> 
> apparently hasn't been fixed.  Why not?

People I know in person have mentioned this to me directly which is why 
I added this. I think this is actually better fixed in tab-line.el, 
though. tab-line-mode has the same issue.  If you think it's more useful 
to file a separate bug for this, I can do so and delete this as a known 
issue of window-tool-bar.

  -- MJF

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

From: Jared Finder <jared <at> finder.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Sun, 02 Feb 2025 13:19:58 -0800

[Message part 1 (text/plain, inline)]

I forgot to attach the patch, sorry. Now attached.

On 2025-02-02 13:17, Jared Finder wrote:
> On 2025-02-02 00:52, martin rudalics wrote:
>>> Thanks.  Martin, any comments?
>> 
>> Just the obvious: "The meanining is ..." should be fixed and "can not"
>> should become "cannot".
> 
> Thanks. Typos fixed and I added a mapping to 
> customize-package-emacs-version-alist.
> 
>> BTW this
>> 
>> ;; Dragging empty space on the tab-line (which this package uses to
>> ;; display the window tool bar) doesn't resize windows.  This is
>> ;; unlike the mode line, where dragging empty space resizes the
>> ;; window.
>> 
>> apparently hasn't been fixed.  Why not?
> 
> People I know in person have mentioned this to me directly which is why 
> I added this. I think this is actually better fixed in tab-line.el, 
> though. tab-line-mode has the same issue.  If you think it's more 
> useful to file a separate bug for this, I can do so and delete this as 
> a known issue of window-tool-bar.
> 
>   -- MJF

[0001-Update-window-tool-bar.patch (text/x-diff, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Jared Finder <jared <at> finder.org>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Mon, 03 Feb 2025 09:36:38 +0200

>> BTW this
>> ;; Dragging empty space on the tab-line (which this package uses to
>> ;; display the window tool bar) doesn't resize windows.  This is
>> ;; unlike the mode line, where dragging empty space resizes the
>> ;; window.
>> apparently hasn't been fixed.  Why not?
>
> People I know in person have mentioned this to me directly which is why
> I added this. I think this is actually better fixed in tab-line.el,
> though. tab-line-mode has the same issue.  If you think it's more useful to
> file a separate bug for this, I can do so and delete this as a known issue
> of window-tool-bar.

Dragging empty space on the tab-line would be nice to have
when it doesn't preclude from dragging tabs to reorder them.
Please file a separate request if you intend to implement this.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, Jared Finder <jared <at> finder.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Mon, 3 Feb 2025 09:33:32 +0100

> Dragging empty space on the tab-line would be nice to have
> when it doesn't preclude from dragging tabs to reorder them.
> Please file a separate request if you intend to implement this.

I don't overly like that empty space dragging anyway.  For me the best
solution would be to use a uniform 8-dot Braille pattern on both sides
to indicate the locations from where one can start dragging any of these
lines.

martin

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

From: Jared Finder <jared <at> finder.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Mon, 03 Feb 2025 22:20:08 -0800

On 2025-02-02 23:36, Juri Linkov wrote:
>>> BTW this
>>> ;; Dragging empty space on the tab-line (which this package uses to
>>> ;; display the window tool bar) doesn't resize windows.  This is
>>> ;; unlike the mode line, where dragging empty space resizes the
>>> ;; window.
>>> apparently hasn't been fixed.  Why not?
>> 
>> People I know in person have mentioned this to me directly which is 
>> why
>> I added this. I think this is actually better fixed in tab-line.el,
>> though. tab-line-mode has the same issue.  If you think it's more 
>> useful to
>> file a separate bug for this, I can do so and delete this as a known 
>> issue
>> of window-tool-bar.
> 
> Dragging empty space on the tab-line would be nice to have
> when it doesn't preclude from dragging tabs to reorder them.
> Please file a separate request if you intend to implement this.

Will do. It's especially strange since dragging on a header line *does* 
resize the window. If you have a header line and a tab line both 
visible, you end up with the following stack at the boundary between 
windows:

Top window content
--- MINIBUFFER --- (draggable)
--- TAB LINE ----- (not draggable)
--- HEADER LINE -- (draggable)
Bottom window content

I'll file a separate bug for making dragging empty space on the tab line 
work and will delete this line from the patch next time I'm near my 
Emacs-development computer.

Any other feedback here?

  -- MJF

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

From: Juri Linkov <juri <at> linkov.net>
To: Jared Finder <jared <at> finder.org>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Tue, 04 Feb 2025 09:40:19 +0200

>>>> BTW this
>>>> ;; Dragging empty space on the tab-line (which this package uses to
>>>> ;; display the window tool bar) doesn't resize windows.  This is
>>>> ;; unlike the mode line, where dragging empty space resizes the
>>>> ;; window.
>>>> apparently hasn't been fixed.  Why not?
>>> People I know in person have mentioned this to me directly which is why
>>> I added this. I think this is actually better fixed in tab-line.el,
>>> though. tab-line-mode has the same issue.  If you think it's more useful
>>> to
>>> file a separate bug for this, I can do so and delete this as a known
>>> issue
>>> of window-tool-bar.
>> Dragging empty space on the tab-line would be nice to have
>> when it doesn't preclude from dragging tabs to reorder them.
>> Please file a separate request if you intend to implement this.
>
> Will do. It's especially strange since dragging on a header line *does*
> resize the window. If you have a header line and a tab line both visible,
> you end up with the following stack at the boundary between windows:
>
> Top window content
> --- MINIBUFFER --- (draggable)
> --- TAB LINE ----- (not draggable)
> --- HEADER LINE -- (draggable)
> Bottom window content

Indeed, this omission is especially glaring in this case.

It's interesting to note that hovering over the mode line changes
the mouse icon to indicate resizing, but hovering over the header line
doesn't change the mouse icon, so no indication that it's draggable.

> I'll file a separate bug for making dragging empty space on the tab line
> work and will delete this line from the patch next time I'm near my
> Emacs-development computer.

Thanks in advance.

> Any other feedback here?

I have no more feedback.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jared Finder <jared <at> finder.org>, Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Tue, 4 Feb 2025 09:09:53 +0100

> --- MINIBUFFER --- (draggable)

Strictly spoken a MINIBUFFER is not draggable.  The mode line above is.

martin

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

From: Jared Finder <jared <at> finder.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 75844 <at> debbugs.gnu.org
Subject: Re: bug#75844: Update for window-tool-bar
Date: Wed, 05 Feb 2025 21:47:38 -0800

[Message part 1 (text/plain, inline)]

On 2025-02-03 23:40, Juri Linkov wrote:
>>>>> BTW this
>>>>> ;; Dragging empty space on the tab-line (which this package uses to
>>>>> ;; display the window tool bar) doesn't resize windows.  This is
>>>>> ;; unlike the mode line, where dragging empty space resizes the
>>>>> ;; window.
>>>>> apparently hasn't been fixed.  Why not?
>>>> People I know in person have mentioned this to me directly which is 
>>>> why
>>>> I added this. I think this is actually better fixed in tab-line.el,
>>>> though. tab-line-mode has the same issue.  If you think it's more 
>>>> useful
>>>> to
>>>> file a separate bug for this, I can do so and delete this as a known
>>>> issue
>>>> of window-tool-bar.
>>> Dragging empty space on the tab-line would be nice to have
>>> when it doesn't preclude from dragging tabs to reorder them.
>>> Please file a separate request if you intend to implement this.
>> 
>> Will do.
...
>> Any other feedback here?
> 
> I have no more feedback.

Attached is a patch with the issue around dragging the header line not 
mentioned. I'll be filing a bug immediately after this to track fixing 
header line dragging (it will take a bit longer to address).

  -- MJF

[0001-Update-window-tool-bar.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: rudalics <at> gmx.at, 75844 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#75844: Update for window-tool-bar
Date: Thu, 06 Feb 2025 11:34:15 +0200

> Date: Wed, 05 Feb 2025 21:47:38 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
>  75844 <at> debbugs.gnu.org
> 
> > I have no more feedback.
> 
> Attached is a patch with the issue around dragging the header line not 
> mentioned. I'll be filing a bug immediately after this to track fixing 
> header line dragging (it will take a bit longer to address).

Thanks, a few minor comments below.

> +@vindex window-tool-bar-style
> +@cindex Window Tool Bar style

Index entries should preferably be all-lowercase, to make sure their
sorting does not depend on the locale where the manual is generated.

> +On graphical displays the window tool bar can be displayed in multiple
> +different styles.

I'd use "several".  "Multiple" could be interpreted as meaning "at the
same time", which is not what you mean.

> +On text-only displays the window tool bar only shows text for each
> +button.

I'm guessing you mean "even if another style is specified", right?
If so, please say so explicitly.

> +(defcustom window-tool-bar-style 'image
> +  "Tool bar style to use for window tool bars.
> +The meaning is the same as for `tool-bar-style', which see.  If
> +set to the symbol `tool-bar-style', then use the value of
> +`tool-bar-style' instead.
> +
> +When images cannot be displayed (see `display-images-p'), text
> +is used."

Passive tense alert!

> +  :type '(choice (const :tag "Images" :value image)
> +                 (const :tag "Text" :value text)
> +                 ;; This option would require multiple tool bar lines.
> +                 ;;(const :tag "Both" :value both)
> +                 (const :tag "Both-horiz" :value both-horiz)
> +                 (const :tag "Text-image-horiz" :value text-image-horiz)
> +                 (const :tag "Inherit tool-bar-style" :value tool-bar-style)
> +                 (const :tag "System default" :value nil))

Many of these tags have cryptic text.  Can we make this text more
user-friendly?  It is there to explain the meaning of each value to
the users when they customize the option.

> +(defun window-tool-bar--style ()
> +  "Return the effective style based on `window-tool-bar-style'.
> +
> +This also takes into account frame capabilities.  If the current
> +frame cannot display images (see `display-images-p'), then this
> +will always return text."
> +  (if (not (display-images-p))
> +      'text

Should we perhaps test for support of specific image types?

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

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 75844 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#75844: Update for window-tool-bar
Date: Thu, 06 Feb 2025 14:49:56 -0800

[Message part 1 (text/plain, inline)]

On 2025-02-06 01:34, Eli Zaretskii wrote:
>> Date: Wed, 05 Feb 2025 21:47:38 -0800
>> From: Jared Finder <jared <at> finder.org>
>> Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
>>  75844 <at> debbugs.gnu.org
>> 
>> > I have no more feedback.
>> 
>> Attached is a patch with the issue around dragging the header line not
>> mentioned. I'll be filing a bug immediately after this to track fixing
>> header line dragging (it will take a bit longer to address).
> 
> Thanks, a few minor comments below.

Almost all comments addressed.  Some additional follow-up...

>> +@vindex window-tool-bar-style
>> +@cindex Window Tool Bar style
> 
> Index entries should preferably be all-lowercase, to make sure their
> sorting does not depend on the locale where the manual is generated.

0002.patch also does this for tool-bar-mode docs.

>> +  :type '(choice (const :tag "Images" :value image)
>> +                 (const :tag "Text" :value text)
>> +                 ;; This option would require multiple tool bar 
>> lines.
>> +                 ;;(const :tag "Both" :value both)
>> +                 (const :tag "Both-horiz" :value both-horiz)
>> +                 (const :tag "Text-image-horiz" :value 
>> text-image-horiz)
>> +                 (const :tag "Inherit tool-bar-style" :value 
>> tool-bar-style)
>> +                 (const :tag "System default" :value nil))
> 
> Many of these tags have cryptic text.  Can we make this text more
> user-friendly?  It is there to explain the meaning of each value to
> the users when they customize the option.

This too.

>> +(defun window-tool-bar--style ()
>> +  "Return the effective style based on `window-tool-bar-style'.
>> +
>> +This also takes into account frame capabilities.  If the current
>> +frame cannot display images (see `display-images-p'), then this
>> +will always return text."
>> +  (if (not (display-images-p))
>> +      'text
> 
> Should we perhaps test for support of specific image types?

I don't think type checks are needed.  A tool bar keymap entries' :image 
property gets built by tool-bar--image-expression which uses find-image 
to get the best supported image format for an icon.

  -- MJF

[0001-Update-window-tool-bar.patch (text/x-diff, attachment)]

[0002-Cleanup-tool-bar-mode-documentation.patch (text/x-diff, attachment)]

Message #46 received at 75844-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: rudalics <at> gmx.at, 75844-done <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#75844: Update for window-tool-bar
Date: Sat, 08 Feb 2025 13:15:47 +0200

> Date: Thu, 06 Feb 2025 14:49:56 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: juri <at> linkov.net, rudalics <at> gmx.at, 75844 <at> debbugs.gnu.org
> 
> >> Attached is a patch with the issue around dragging the header line not
> >> mentioned. I'll be filing a bug immediately after this to track fixing
> >> header line dragging (it will take a bit longer to address).
> > 
> > Thanks, a few minor comments below.
> 
> Almost all comments addressed.  Some additional follow-up...
> 
> >> +@vindex window-tool-bar-style
> >> +@cindex Window Tool Bar style
> > 
> > Index entries should preferably be all-lowercase, to make sure their
> > sorting does not depend on the locale where the manual is generated.
> 
> 0002.patch also does this for tool-bar-mode docs.
> 
> >> +  :type '(choice (const :tag "Images" :value image)
> >> +                 (const :tag "Text" :value text)
> >> +                 ;; This option would require multiple tool bar 
> >> lines.
> >> +                 ;;(const :tag "Both" :value both)
> >> +                 (const :tag "Both-horiz" :value both-horiz)
> >> +                 (const :tag "Text-image-horiz" :value 
> >> text-image-horiz)
> >> +                 (const :tag "Inherit tool-bar-style" :value 
> >> tool-bar-style)
> >> +                 (const :tag "System default" :value nil))
> > 
> > Many of these tags have cryptic text.  Can we make this text more
> > user-friendly?  It is there to explain the meaning of each value to
> > the users when they customize the option.
> 
> This too.
> 
> >> +(defun window-tool-bar--style ()
> >> +  "Return the effective style based on `window-tool-bar-style'.
> >> +
> >> +This also takes into account frame capabilities.  If the current
> >> +frame cannot display images (see `display-images-p'), then this
> >> +will always return text."
> >> +  (if (not (display-images-p))
> >> +      'text
> > 
> > Should we perhaps test for support of specific image types?
> 
> I don't think type checks are needed.  A tool bar keymap entries' :image 
> property gets built by tool-bar--image-expression which uses find-image 
> to get the best supported image format for an icon.

Thanks, installed on the master branch, and closing the bug.

Previous Next

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