@JimiC Can you make the changes minimal? No let to const or convert functions to methods unless really necessary.

@aeschli Sure. I so much guessed that all these changes will not make the code review an easy task.

@aeschli Submitted code with minimal changes.

What's the latest status on this PR? I use vscode-icons, but the constant reloading is really starting to get annoying, heh.

@aeschli
I have resolved the conflicts with master. Do we have any news on the fate of this PR?

Sorry, I was out for 2 month. The code changes to the theme service look good to me, but the controversial part are the APIs. They don't fit with the existing vscode APIs and contribution points. We have no other API that signals that a static contribution point (or parts of it) needs to be reloaded.

I think the proper ways would be:

• no new API but we add a file watch to the currently active file icon (and color) theme definition file. On file change the theme is automatically reloaded. That would also enable theme authors to try out changes directly in the theme file.

• new API that allows to programmatically provide a icon theme and change event?

Would the first suggestion work for you?

@aeschli A watcher over the icon definition file would do the job as well.

Is there somewhere in the code-base a similar case so I can have a look at it and maybe provide a revised PR?

The fileService has methods watchFileChange/unwatchFileChanges to enable/disable the watcher, onFileChanges is the event to listen to.

Closing in favor of #66115