Custom icon in Dock no longer displays in TF 1.9 or higher

Prior to versions of 1.9 of TF, if I had the preferences set to Keep Original Dock icon, the Dock would display the custom Finder.png icon that I substituted in System\Library\CoreServices\\Content\Resources\finder.png.

Since version 1.9 and higher, the Dock now displays Apple’s default Finder image in the dock (i.e. the half blue/white smiley face Mac). I am very aware about the need to delete icon cache and restart Dock, etc, so that is not the issue. If I clear the cache and restart the Dock, I BRIEFLY do see my custom Finder icon. The minute I open Finder (and therefore TF as well), after a few seconds, the icon in the Dock changes from my custom icon back to the Apple default.

Then I thought well maybe I can use reverse thinking, change the /Applications/ file and set preferences to use the TF dock icon, but now with code signing, it is not possible to modify the (which is understandable)

Any idea why this behavior changed? I have another system still using TF 1.8.2 (both are running El Cap) and the custom Finder icon in the Dock displays correctly.

I’m not aware of any changes to relevant code.

This is how I lookup original Finder icon:

originalFinderIcon = [[NSBundle bundleWithPath:[[NSWorkspace sharedWorkspace] fullPathForApplication:@"Dock"]] imageForResource:@"finder"];

I will investigate it and find a solution so you can have a custom Dock icon (even with codesign checks).

I appear to have solved it. That function call appears to initiate a recall to the Generate Image routine called by ‘icon services agent’, which takes the image in the PNG or ICNS file of a resource and generates a raw pixel image that the system can use to quickly display, and then caches it. That call, I believe, does retrieve the ‘finder.png’ file in the resource folder. The size of the PNG file I used for finder.png was 444 pixel square at 72dpi. I had been using that same png file of that size with previous versions of TF prior to 1.9 with no problems. macOS would scale down the image as needed based on the Dock size. For some reason that behavior changed via some combination of TF or macOS GenerateImage routine in El Capitan, once TF loads. As noted, the image is fine prior to TF loading, but once TF loads, it results in calling Generate Image again and the second call fails. I realized this seeing the error in the Console log right after TF finishes its injection routine.

When I resized the png file to 128 pixel sq at 72dpi, which is the same size as Apple’s default finder.png file, Viola! the custom icon displays correctly even after TF loads. I then tried 256x256 and that worked. Once I went beyond 256x256, it fails. So the moral of the story for everyone, is whatever Apple icon you are replacing, including custom sidebar icons, be sure to use the same pixel size and dpi as Apple’s original, or in the case of a custom sidebar icon, don’t get larger than 256x256. From what I can tell, most of Apple’s default folder icons in CoreServices.bundle/Resources do not exceed 128x128 and all use 72 dpi. probably best not to exceed 128x128 just be safe. If you have Retina display, the system is going ignore the “regular” png file anyway and use the one ending in ‘@2x’ which are double the size of the regular version . Strangely this MAY only be an issue with combination of El Cap 10.11.6 and TF 1.9.x. I have a system with Yosemite and TF 1.9.3, using the large 444x444 image, and it works fine. Haven’t tried Sierra. Sorry to waste your time Darwin, thank you. BTW, Im the same guy who wrote up the brief description to document how to modify icon2.plist (and now .totalfinder-sidebar-icons.plist) at Feature request: custom icons in sidebar

I don’t think you have documented this anywhere else? Feel free to use and modify my post there if you wish and post as a tip.

Interesting. Thanks for your detailed investigation and explanation.

I will at least add another hidden tweak which prevents TotalFinder from altering the Dock icon at all. Right now it touches it regardless of your preferences, because it could need to render progress bar on top of it if enabled.