I love this theme but want to add my own colour variations for certain icons, for more specific custom file sub-types (in the form of *.something.ext). It's very simple to copy the .svg files in the material-icons extension folder, edit the fill colour and create custom identifiers in the .json file - however, these changes are lost with any extension updates.
It feels like it would be way simpler to just allow users to link their own icon files in the material-icon-theme.files.associations, where instead of the identifier (eg. "angular-component"), you could just pass a full file path to the .svg file.
I would have thought this would be fairly simple to implement, and it would greatly enhance the scope of the extension.
[closed by accident]
I've just discovered that you can already do this - though it seems to be possible purely by accident, and so is slightly hacky. Just add your file association in the form:
"*.custom.ext": "[filepath]"
This is exactly as I was wanting! The only catch is that [filepath] has to be relative... to the extension icon folder. So if you want to store your custom icons in another folder somewhere else, you've got to start your file path ../../../../ to get into your home directory and then go from there (on Linux, anyway). Oh and lastly, you've got to leave off the .svg at the end of your custom file path, as it seems to be added automatically in the handling of the string.
It should be trivial to alter the code to support absolute file paths, support folder names with capitals, (which I noticed it converts to lower-case, braking the file path. Spaces may also break it, I didn't test this though), and be agnostic about the inclusion of '.svg' at the end of the file path. You could check for a / at the start of or within the icon identifier string to tell if you were dealing with a file path.
Hi, yes you can customize the icons directly in the material-icons.json file. The implementation of such a feature will be risky because custom icons could break the overall experience like adjustments in opacity or saturation of the icons. Same for the conflicts that could occur in file extensions and their icon associations. I think if you really want to customize it on your own then it is currently the best way to adjust the extension directly, even if it's hacky.
Closing as duplicate of #37.
I understand your points about keeping the overall experience clean, and most people are probably fine with just the existing icons. However, editing the extension directly is a no-go for me because I really don't want to have to re-do my changes every time it gets updated.
Conflicts with icons for a certain extension surely aren't an issue though, as any customisations would just override the defaults? And you could always add the possibility of adding custom icon extension associations by file path directly, and in the docs describe the feature as a footnote, whilst making it clear that it won't necessarily play nice with some of the overall features. That way it would be there for those that would like it and don't use the saturation/opacity (or don't mind the inconsistencies).
That said, as I noted in my last comment, you can already add custom icons via the material-icon-theme.files.associations setting if you specify the file path relative to the extension icons folder (apparently just as a quirk of the way the extension was written). This works fine for my use case, and I understand that adding proper support for this feature might not be your priority / fit with your vision for the extension. So no worries, but please don't refactor out this accidental functionality in an update!
If you were feeling fancy, you could always add support for transparency/saturation in custom icons with a find-parse-adjust-replace approach on any color codes in the text of the custom .svg files! Probably unnecessary though, and I don't know if it would cover all the bases anyway ;)
Sorry, I unfortunately misunderstood what you wrote about customizing the existing material-icon-theme.files.associations setting. I didn't know that either. Thanks for figuring that out, this is really nice. I directly tried to paste an absolute path like "iconPath": "C:\\Users\\pkief\\icons\\adonis.svg" to the generated material-icons.json file which is located in the extension folder. The issue is that VS Code automatically applies a relative path and it tells me that it could not find the SVG icon at file:///C:/Users/pkief/.vscode/extensions/pkief.material-icon-theme-4.2.0/dist/C:/Users/pkief/icons/adonis.svg. It simply appends the string of the setting to the path of the dist directory of this extension. It's a default behavior of VS Code and I have no option to change this behavior from the code of the extension. The extension simply generates the json and VS Code uses it to load the icons. I could generate a "../../../../" depending on how many levels we would have to go up to resolve this absolute path, but I'm not sure if it's worth the effort also regarding with OS specific paths and the portable version of VS Code. So I think this relative path is should be good for now.
But again, thanks for figuring that out. It will definitely not be removed, it's a feature, of course 馃か馃槈
I've documented the possibility of adding new SVG icons to the theme here:
https://github.com/PKief/vscode-material-icon-theme#custom-svg-icons
Most helpful comment
Sorry, I unfortunately misunderstood what you wrote about customizing the existing
material-icon-theme.files.associationssetting. I didn't know that either. Thanks for figuring that out, this is really nice. I directly tried to paste an absolute path like"iconPath": "C:\\Users\\pkief\\icons\\adonis.svg"to the generated material-icons.json file which is located in the extension folder. The issue is that VS Code automatically applies a relative path and it tells me that it could not find the SVG icon atfile:///C:/Users/pkief/.vscode/extensions/pkief.material-icon-theme-4.2.0/dist/C:/Users/pkief/icons/adonis.svg. It simply appends the string of the setting to the path of thedistdirectory of this extension. It's a default behavior of VS Code and I have no option to change this behavior from the code of the extension. The extension simply generates the json and VS Code uses it to load the icons. I could generate a "../../../../" depending on how many levels we would have to go up to resolve this absolute path, but I'm not sure if it's worth the effort also regarding with OS specific paths and the portable version of VS Code. So I think this relative path is should be good for now.But again, thanks for figuring that out. It will definitely not be removed, it's a feature, of course 馃か馃槈