Discontinue custom functionality support and get fully official

[robertohuertasm]

According to vscode #11751 next vscode release ❤️ will support icons here:

• open editors view
• tabs
• title in editor when tabs are disabled
• search results
• problems
• quick open / editor pickers

I'm thinking of removing all the custom functionality which now will only get reduced to:

• show/hide folders
• show/hide some specific icons
• show/hide tab icons
• show/hide open editors
• associate icons via regex

I'm fairly certain that VSCode team will implement at least these show/hide options in order to let the user choose where to show his/her icons.

For us it will allow us to get rid of all the admin rights madness and all these "hacky" implementations.

@bpasero, @aeschli are you planning to let the users enable / disable certain icon appearances?

I'm willing to leave the unofficial support as this is creating some issues to the VSCode team and it looks to me that this next release is the right time to do it. The main point of making this extension was bringing icons to VSCode and here they are. It's just a matter of time for this functionality to evolve inside the VSCode project and hopefully they will provide some kind of user abilities in order to allow support for custom extensions (e.g. webpack.config.*.js)

It's not a final decision but I somehow feel that this is the end of a cycle. Any thoughts?

[jens1o]

Please, please support "associate icons via regex"... I kinda like it, and some icons can't be bound, because of these various file endings, for example Webconfig. (For example *.meta.tpl is json in my enviroment, but I still need the tpl Functions there)

These show/hide should be supported till Code supports it. I really like these options...

[robertohuertasm]

I think maybe we should create some issues in VSCode's GitHub project asking for these kind of functionality and see what they have to say.

[bpasero]

+1 of retiring this extension in favour of built in VS Code functionality. Currently, we do not provide options to selectively enable/disable icons. Does vscode-icons have fine granular options for each and every area where icons can show up?

[robertohuertasm]

@bpasero yes it does. I'm more concerned about custom icon association than these hide/show options, which has proven to be useful when you have to support scenarios where you have files with a semi-variable extension, i.e webpack.config..js.

With vscode-icons the user can associate any icon to regex so this can be achieved. We would need something similar in the built-in functionality (maybe the use of globs when defining file name associations). It would be really great to have it. With the arrival of full icon support from your side I see no other reason to keep supporting these kind of hacks except for this. Some of the current extension users are actively using it. I think it would allow icon theme creators to support wide icon usage scenarios.

@bpasero just a note: the idea is not retiring the extension (which currently supports the official VS Code functionality) but to remove all the injecting part of it. 😉

[bpasero]

Yeah sure, keep the extension but provide an official icon theme. We do support file associations in settings and it has some simple glob support. However it seems what you refer to is a way to map a regex to a icon? In our world, the file association is a mapping of glob to language and from the language we determine the icon.

[robertohuertasm]

We currently provide an official icon theme 😁 To be honest I haven't take a look at your current implementation so I don't really know how this could be accomplished or even whether this could be accomplished. I'll take a look just out of curiosity to see if this can be extended in any way.

Now, when we define a filename association (using the official theme api) we provide the file name and the icon definition:

"fileNames": {
    "appveyor.yml": "_f_appveyor"
}

What I was asking was something similar to this:

"fileNames": {
    "appveyor.*.yml": "_f_appveyor" // note the *
}

This will allow to cover any custom scenario like appveyor.dev.yml, appveyor.prod.yml and so on.

[bpasero]

@robertohuertasm I see, I leave it up to @aeschli to comment on such a support

[bpasero]

I pushed a new setting to control if icons should show up for editors or not (workbench.editor.showIcons). My feeling is that we should not introduce more settings for each place in the UI because all the other places are trees (explorer, opened editors, search, problems, quick open) and if the user wants to see icons where we show file names in trees, I think it is fair to show them consitently in all trees.

[robertohuertasm]

After seeing vscode #12493 I think it's time to move on and go fully official. I see no reason to keep the hacks. It's becoming a nightmare to try to keep up with the Insiders changes and the value that they add it's not worth it anymore, taking into account that VSCode team is providing great support for icons and it's going to continue exploring new features if the community asks for them.

I've created a new 3.0 milestone in order to remove the custom functionalities and only provide the icons disable functionality so that people that already have the custom functionality enabled can disable it without having to reinstall.

If someone wants to keep the old functionality, the code is here so it's all yours, but this repo is going to get rid of it and become a standard icon theme and so the associated extension in the Marketplace. I'm determined to that right now as I cannot see any point on continuing with the hacks once the main goal of the extension has been completely achieved.

[robertohuertasm]

Currently on hold, after seeing that vscode #12493 is not still solved...

[robertohuertasm]

Dropping hack functionality support for VSCode >= 1.6.0 See #347

[robertohuertasm]

vscode-icons' readme now provides a link to #12493. User's support is key in order to show whether this functionality is needed or not.

[kristianmandrup]

Please add ability to assign custom icons to extension such as .test.js or .spec.js - thanks!