Evaluate file icons contributions

[aeschli]

vscode-icons is a very popular extension. It adds icons to file explorer. Unfortunately it has to use a rather hackish way to implement that. This issue evaluates whether and how we would enable file icon contributions through a regular extension mechanism.

Built-in icons vs icon set contributions

We see different approaches of increasing flexibility:

1. We design standard file icons for the light and dark themes and add them as to our default icon set. We provide a settings UI to turn on/off icons. No mechanism/API for replacing the icons.
   • + consistent UI
   • - not very innovation friendly
   • - we cannot provide icons for all file types out there
2. Contribution point for providing a file icon set. We provide a settings UI to configure which file icons set to show. Includes a picker or code completions to browse icon sets.
   • + innovation friendly
   • + cooperate with vscode-icons author Roberto Huertas to migrate to the new contribution point.
3. Yeoman generator that let you convert existing file icon sets like Seti to a VSCode icon set
4. Extend an icon set by adding icons for new file suffices.

Conclusion: We would head for level 2 at first. Open question is whether we should provide a default icon set or not. Maybe a VS icon set? We could also start with pointing the user into the market place to install icons set similar to how we now point to the marketplace for themes from the picker.

Workbench theme vs. separate file icons packs.

• have file icons as part of workbench theming, like sublime does it
  • + provides a full workbench theme experience, from colors, animations to icon and tab styles.
  • - user might not like that icons are coupled with other theming that might be unwanted
  • - authoring a full theme is non-trivial and time intensive
  • - implementing workbench theming is a lot of work for which we are quite far away from. There are also not that many requests for it.
• have file icons contributions separate.
  • - limited but file icons can still be part of a future workbench theming story
  • + more flexible

Conclusion: We want to look at file icon contributions. This is what is most requested. When done thoughtfully will not prevent workbench themes in the future but just be a building block.

2 bit (glyph) vs. Multi color icons

• - limiting
• + only one set of icons needed to for both glyph both light and dark theme. Each icon can still have a individual foreground color for the light and dark theme.
• + glyph icons would play nice with the rest of our UI (see status line)

PNG vs. SVG vs Fonts

While PNG is likely the lowest barrier for users, we need to have a solution for scaling icons.
Fonts are attractive from a performance and scaling standpoint, but not easy to handle by users.

Note, the Atom Seti extension uses fonts and has built some tooling so that fonts can be extended by new icons.

[aeschli]

We've added a new contribution point 'iconThemes'. See #10804 for more information