Add support for macOS accent colors

[Neved4]

• Fixes: folder colors on Tahoe #101 MacOS 26 Folder color unification #102
• Partially addresses: [Request] Ability to change the folder color #72

---

Support macOS Tahoe accent colors for folder icons.
Also adjusted mask placement and shading to fit them better on other tints.

Hope you're having a great day! 🤍

[lgarron]

I'm not aware of a change for the default Tahoe folder color from turquoise to blue. Are you using an OS color setting?

Supporting additional folder colors is a larger issue in itself: #101

[Neved4]

@lgarron Thx! You're right someone made me aware of this but you got to it sooner! The idea would be to support all accent colors, working on it!

[Neved4]

Should be ready to go!

[lgarron]

Thanks for the contribution! I'll have to comb through it but first need to ask:

• Where are the folder icons sourced from?
• Were any of these changes not fully authored by you (e.g. with the help of an LLM)?

[Neved4]

Made sure that --folder-color appears on --help and that we auto-detect the user selected color which was missing

[Neved4]

Thanks for the contribution!

No worries 🤍

Where are the folder icons sourced from?

Great question! Didn't know where you src'd them from initially so had to reverse it and did a (very) hacky Python script (god bless) with some Swift pieces. Used to do these kinds of things (still remember fondly this I had to do without agents: nicolargo/glances#2867, nicolargo/glances#2877, nicolargo/glances#2866, nicolargo/glances#2817, nicolargo/glances#2876)

On top of that, generally this kind of stuff the places to hunt for are at either:
CoreTypes: /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Assets.car
Finder: /System/Library/CoreServices/Finder.app/Contents/Resources/Assets.car
IconsetRes: /System/Library/CoreServices/IconsetResources.bundle/Contents/Resources/Assets.car

So that's where the folder icons are stored as multi-layer assets inside a Assets.car. Since we didn't have a generation script, thought best to commit them but it'd be possible in the future for folderify to not have the assets prepackaged and instead deduce them from the system during execution? It's likely that when we gain popularity Apple might not like the assets committed to the repo, so that we generate them dynamically. Out of scope but dropping it as an idea

But effectively the color variants don't live inside .car. So had to derive them from macOS built-in GenericFolderIcon, as in calling NSWorkspace.sharedWorkspace().iconForFile_() and such allows you to retrieve them via the IconServices daemon. My Swift code dynamically changes the system color and asks NSWorkspace to render the resulting icon. Basically leveraging the same process that the system uses

Were any of these changes not fully authored by you (e.g. with the help of an LLM)?

Yea relate to your concern here. Leveraged it some for the Rust bits to not fight with the compiler since it's not a language that feel personally confident with debugging every single possible error by hand. Do think that test_auto_folder_color_matches_current_system_expectations() has to go or reworked since it adds no real value. And that the expect() for the auto value could be improved

Overall reviewed and finalized the code and assets myself, as such will make myself responsible and won't delegate review or follow-ups to anything automated out of basic respect, if you prefer I could add a short note describing the asset sourcing/process explicitly

Have a great day! Cheers,
Neved4