Re: Add Tango and Adwaita icons for the toolbar

[Yuan Fu <casouri@gmail.com>]

> On May 4, 2024, at 2:48 AM, Po Lu <luangruo@yahoo.com> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> Hey guys,
>> 
>> I followed the original tool-bar icon thread in 2022. At the time I
>> didn’t have much time and I personally prefer colorful icons for the
>> tool bar [1] (IMO mono-colored symbolic icons are more suitable for
>> inline, small icons), so I didn’t do anything except for observing the
>> discussion.
>> 
>> [1] I especially adore the life ring icon for help! Whatever icon set
>> we use for the tool-bar, the help icon should always be a cute life
>> ring :-)
>> 
>> The recent Emacs app icon thread reminded me of that thread, and I do
>> have time now. So, I went ahead and searched for the Tango and Adwaita
>> icons (basically the high-res version of the existing tool-bar icon
>> that we use), then converted them to be suitable for Emacs tool-bar.
>> 
>> About 1/3 of the icons can be directly taken from Tango or Adwaita,
>> the rest I have to modify or kind of take apart and
>> re-assemble. Anyway, in the end I managed to get most of the basic
>> icons covered. For details see etc/images/scalable/README.
>> 
>> You can see the attached screenshots for the current built-in icons
>> and the new icons. I also attached the patch for it. You want to
>> rebuild or byte-compile tool-bar.el for the new icons to take effect.
>> 
>> I hope these new icons won’t be controversial. As you can see, they
>> are basically straight high-res upgrades for the existing icons. There
>> are many imperfections that’ll be atrocious in the eyes of a graphic
>> designer—I did the conversion work in an afternoon and I’m no where
>> near a graphic designer; but it’s definitely an upgrade and we can
>> always incrementally improve after.
> 
> They will not be controversial if it is possible to opt out of them, and
> enough of the icons are replaced that none of us encounter tool-bars
> bearing an unsightly mixture of old and new.  That is to say:
> 
> Please generate XPM and monochrome PBM versions of the new icons
> introduced, these being the only two image formats implemented without
> dependencies in image.c, and enable SVG only on systems where the
> scalable versions produce a visible improvement to image quality.
> Finally, please see that _all_ major modes are covered by this new icon
> set, including but not limited to message-mode, Doc View,
> xwidget-webkit, and anywhere else a custom tool-bar-map is defined, and
> that there is means of reverting to the old set of icons, for users who
> are so inclined.

I don’t think it’s necessary to generate XPM and BPM versions, because if you compare the new icons with the old, you’ll find that they are essentially the same icon (same shape, motif, etc). That is to say, we already have XPM and BPM version of the icons: the current ones.

Also the icons are in png format, the source is svg, but I exported the svg into png. Because svg isn’t rendered very well, presumably because theses icons are relatively complicated? (More complicated than the symbolic icons for sure.)

As for opting-out, there isn’t a mechanism to explicitly choose what version of icons to use in tool-bar.el right now. So it’ll need to be added. I believe the branch mentioned in the original discussion, created by Stefan K, has some mechanism for an “icon theme”. Maybe we can merge that, plus the new monotone icons in that branch, but left out changing the tool-bar icons?

It’ll be a big project to find counterparts for all the current icons, plus I’m not a designer so I can’t conjure up icons by myself :-) I think we could make it opt-in first, and make it default when we have full coverage.

> The PBM icons should not be unmodified ImageMagick output, they should
> be modified for legibility on actual monochrome displays.  The other day
> there was a post to help-gnu-emacs from an Android user with a
> monochrome display, so these configurations are by no means irrelevant.
> 
>> If no one objects, I’ll happily push this to master.
> 
> Nobody objects to these icons in principle, but do not push such changes
> until they are complete and have been tested by an adequately wide
> audience.  Let it not be forgotten that we are still contending with the
> fallout from another enormously premature change.

Yuan