Change:
.pipe(replace('@@NAME_SHORT@@', product.nameShort)) .pipe(replace('@@NAME@@', product.applicationName)) .pipe(replace('@@EXEC@@', `/usr/share/${product.applicationName}/${product.applicationName}`)) <del> .pipe(replace('@@ICON@@', `/usr/share/pixmaps/${product.linuxIconName}.png`)) </del> <ins> .pipe(replace('@@ICON@@', product.linuxIconName)) </ins> .pipe(replace('@@URLPROTOCOL@@', product.urlProtocol)); const appdata = gulp.src('resources/linux/code.appdata.xml', { base: '.' })

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.44.1 OS Version: Ubuntu 19.10 x64 The file installed to the system uses an absolute path to the icon, although the icon is saved to a standard system location for icons (). This is non-standard — files should use only the icon filename (without the extension!) and allow the system to search its icon files — and it breaks compatibility with icon themes. The fix is simple: change the field to be the following: After making that change, Visual Studio Code uses its default icon unless explicitly overridden by an icon theme. (I've made this change myself on every update to for the past few months.) Steps to Reproduce: Visual Studio Code via system package (e.g. DEB). custom icon theme. the icon has not changed. (Then see ) <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.553 --- <!-- score: 0.506 --- <!-- score: 0.5 --- <!-- score: 0.487 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Do you know stuff?
I do, it was changed to absolute to fix another bug
So... what issue do you actually get? Why have you been changing the icon every month?
the icon would need to change each month as the installer replaces the file with customizations each update. The question is, what's the right way considering was petitioning the absolute way as they weren't seeing anything.
I use an icon theme, and the file won't switch like every other app because of the absolute path. prior fix is definitely a weird workaround for what has got to be a problem elsewhere. You should never need to use an absolute path in a file for an icon. I wonder what's up with that?
I'm really not keen on playing ping pong on this.

So, unless we find out a different fix for , we shouldn't revert. It's better for people to see an icon than not to be able to theme it, IMO.
I'd propose leaving this open for now. I'll see if I can find anything about .
Aha!!! I found a likely cause of the original problem (although I cannot comment on that task): if the file has the wrong permissions, the icon will not be visible! Has anyone actually checked that the file was being marked executable () on all systems? (The source also confirms that only the name, without extension, should be used in the field if the icon is in or any of the pathed icon directories. That's how the system works. Permissions would be the main reason that was then, that's often the case on Linux.)
wait, so absolute paths work when the file has wrong permissions but not just the file name?
It's possible. If there was something wrong with using a relative path to in file, then all those users would be unable to see most icons. But they can see 'em not ours. Since the icon file is present in the usual directory, and the conventions are functioning on everything else, the problem must be our file's permissions. Remember that is merely a convention, and different DEs, programs, widgets, and even versions may handle it differently. They all assume it will follow the convention, so if it doesn't, the results will be unpredictable, varying from one implementation to the next — in a word, it's undefined behavior.
YES! That's indeed it. I just checked on my system, and the files are not marked as executable! (This is in ) ! That means, to resolve both this and , you must: the original workaround; go back to using in the and files. placing and in , they must be marked executable, e.g. via I would create the PR myself, but I haven't yet figured out my way around this particular Debian packaging setup.
Yup, definetly agree on this one, had to also change the .desktop file every time to use my icon theme
Here's a build based on my PR, could some people please verify this works fine? If so, I can merge in for the May release (it's a little late to go in for the April release).

I can confirm that the insider build picks up the icon from my icons theme and if I delete the icon from there it will use the default shipped one. Tested on Debian SID. ! ! And when the icon is gone from my icon theme: !
I did not need to modify any files for this. In the base build I need to change the code.desktop file + url-handler file to pick up my icon theme instead by just using the name in order to get it displayed. The insider build arleady did this by default and hence it works just fine without any edits from the user. Your pr works, at least for me
if you could verify too that would be great, should be able to merge this in around 1-2 weeks.
Confirmed that it works! It shows the default, and when I add a custom icon for it to my icon theme, it picks up on the new icon.
Great, I pinged the other issue as well to tell them about the change , I'll merge it in when master is opened for the May release.
Thanks for your analysis!
Looks like a good author-verified situation.