![]() ist) at Feature request: custom icons in sidebar BTW, Im the same guy who wrote up the brief description to document how to modify ist (and now. Sorry to waste your time Darwin, thank you. I have a system with Yosemite and TF 1.9.3, using the large 444x444 image, and it works fine. Strangely this MAY only be an issue with combination of El Cap 10.11.6 and TF 1.9.x. If you have Retina display, the system is going ignore the “regular” png file anyway and use the one ending in ‘ which are double the size of the regular version. probably best not to exceed 128x128 just be safe. 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. 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. 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 realized this seeing the error in the Console log right after TF finishes its injection routine. ![]() 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. For some reason that behavior changed via some combination of TF or macOS GenerateImage routine in El Capitan, once TF loads. macOS would scale down the image as needed based on the Dock size. ![]() I had been using that same png file of that size with previous versions of TF prior to 1.9 with no problems. The size of the PNG file I used for finder.png was 444 pixel square at 72dpi. That call, I believe, does retrieve the ‘finder.png’ file in the Dock.app resource folder. 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. Then I thought well maybe I can use reverse thinking, change the /Applications/TotalFinder.app/Contents/Resources/TotalFinder.bundle/Contents/Resources/TotalFinderLarge.png file and set preferences to use the TF dock icon, but now with code signing, it is not possible to modify the TF.app (which is understandable)Īny 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. ![]() 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. If I clear the cache and restart the Dock, I BRIEFLY do see my custom Finder icon. I am very aware about the need to delete icon cache and restart Dock, etc, so that is not the issue. Since version 1.9 and higher, the Dock now displays Apple’s default Finder image in the dock (i.e. 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\Dock.app\Content\Resources\finder.png. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |