material-icon-theme: change folder color command does not work when the extension is run as a workspace extension

[egamma]

Background: the popular theme PKief.material-icon-theme does not work in VSO. One reason is that the extension is configured to be a strict ui extension "extensionKind": ["ui"].

When configuring the extension so that it can also run as a workspace extension: "extensionKind": ["ui", "workspace"] then the material icon theme is properly applied and rendered. However, the dynamic theme customizations (change folder, change opacity) have no effect. These dynamic theme customization modify the icon definition file and the svgs for the extension. Reloading the window has no effect and these customizations are not honored.

To reproduce the problem:

• configure the material icon theme as a workspace extensions in the user setting:

	"remote.extensionKind": {
		"pkief.material-icon-theme": "workspace"
	}

• open a dev container (e.g. https://github.com/microsoft/vscode-remote-try-node)
• install the material theme
• reload the window and verify that the extension is run as a workspace extension using 'show running extensions'
• run the extension command 'Material Icons: Change Folder Color'. This command changes the color of the default folder.
• the extension detects the changes to setting and updates the icon file in the extension in dist/material-icons.json and regenerates the corresponding folder SVG icons in the icons folder (e.g. folder.svg). It then informs the user to reload the window.

🐛 the change has no effect and the folder color falls back to the default color.

[aeschli]

The extension modifies the icon definition theme file but also the svg-icons it provides (it changes the fill color).
The problem is that for remote extension resources we set the cache header public, max-age=31536000 as we assume that extension resources only change when an extension updates.
The caching helps with for a good window reload experience.

Some ideas:

• ask the author to use a dynamic icon name e.g. encode the background color in the file name
• add a new flag to package.json no_cache or allow to add a query component or a path segment to signal that the resource is 'non-static'
• have a proper icons provider API

[aeschli]

@PKief Would you consider using a different file name per generated folder icon? E.g. folder-00ff00.svg. That way icons can still be cached when the extension is set to remote.

[PKief]

@aeschli I was just elaborating if this would be technically possible. So right now, I do not see any hurdles except the fact that I need to touch various lines of code in my extension. I could definitely try that if it saves you some time ;)

[aeschli]

Sorry for the work on your side. I think it's the most pragmatic change. Officially, resources in extensions are supposed to be static so what your extension does (others do it as well, I know) is not supported . I understand why you do it and there's currently no alternative for you. The proper solution would be a new 'Icon Provider` API, but that's not very high on our backlog.

When you make the suggested change, as an additional benefit I believe the 'reload window' is no longer necessary.

[PKief]

No worries, I can understand that. I put this task on my agenda to work on that soon. And if the 'reload window' is no longer necessary with this approach, it will improve the experience of my extension as well.

[PKief]

@egamma It is now working with this PR PKief/vscode-material-icon-theme#649 in a remote container:

It is also working for the settings 'material-icon-theme.opacity' and 'material-icon-theme.saturation'. The 'reload.window' is not needed anymore, which is really nice!

I'll merge it to my master branch and push an updated version of the extension to the marketplace in the next days. @aeschli Is there anything else that should be done from my side?

[aeschli]

@PKief Thaks a lot.
You can now also update your package.json to:

"extensionKind": ["ui", "workspace"]

That way your extension will run properly in remote windows as well as in the web without the need for us to override extensionKind.