GNU bug report logs -
#75844
Update for window-tool-bar
Previous Next
Reported by: Jared Finder <jared <at> finder.org>
Date: Sat, 25 Jan 2025 22:40:02 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#75844: Update for window-tool-bar
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 75844 <at> debbugs.gnu.org.
--
75844: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75844
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> 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.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (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)]
This bug report was last modified 102 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.