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

Previous Next

Package: emacs;

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

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: 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)]

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.