Support not adding desktop icons

[ferventcoder]

Description helpfully provided by @teknowledgist below

I would love to have a "universal" (i.e. not dependent on the package maintainer) option to prevent/remove a desktop icon. This would need to be an attempt, but I suspect it could be successful most of the time.

Reason

Some installers have a switch to prevent desktop icons, and for those, the installing user can pass those through to the installer via --installarguments. Some package maintainers can/will included code to handle -packageparameters that will allow the package to deal with unwanted icons, but most maintainers do not. Some packages actually add an icon when the installer does not. It is entirely the maintainer's choice, and often out of the control of the installer.

Chocolatey installs are often scripted, and while the scripter could create custom code to manage the icons for each package install, it would be much nicer and more efficient to simply add a switch to the choco install call.

Issue

Identifying which icons to remove.

Mitigation

The most likely successful process for doing this is to track all the shortcut icons before the install, let the install finish, and then remove the new shortcut icons. Then the issue is reduced to determining which icons were dropped on the desktop due to the package as opposed to placed there by a user during the install or by another simultaneous install or process. Further reductions to the risk of false positives:

The switch should have a value (defaulting to ".*") that can be used as a regex match for icon names. That will give the (obviously knowledgeable) installing user fine-tuned control over the icons that are removed. If a value is provided, it should override other checks. It would be highly unusual for an installer to place icons in both the CommonDesktopDirectory and the current user's desktop. If new icons are in both locations, only delete those from the common desktop. Check that the target for each new icon is a subdirectory of the install location before deleting. For package installs for which the install location is not known, attempt a regex match of the $env:ChocolateyPackageName or the SoftwareName to the icon names.

[teknowledgist]

Without a description, the intent of this issue is a little up for grabs, so I'm going to take a stab at it...

I would love to have a "universal" (i.e. not dependent on the package maintainer) option to prevent/remove a desktop icon. This would need to be an attempt, but I suspect it could be successful most of the time.

Reason

Some installers have a switch to prevent desktop icons, and for those, the installing user can pass those through to the installer via --installarguments. Some package maintainers can/will included code to handle -packageparameters that will allow the package to deal with unwanted icons, but most maintainers do not. Some packages actually add an icon when the installer does not. It is entirely the maintainer's choice, and often out of the control of the installer.

Chocolatey installs are often scripted, and while the scripter could create custom code to manage the icons for each package install, it would be much nicer and more efficient to simply add a switch to the choco install call.

Issue

• Identifying which icons to remove.

Mitigation

The most likely successful process for doing this is to track all the shortcut icons before the install, let the install finish, and then remove the new shortcut icons. Then the issue is reduced to determining which icons were dropped on the desktop due to the package as opposed to placed there by a user during the install or by another simultaneous install or process. Further reductions to the risk of false positives:

• The switch should have a value (defaulting to ".*") that can be used as a regex match for icon names. That will give the (obviously knowledgeable) installing user fine-tuned control over the icons that are removed. If a value is provided, it should override other checks.
• It would be highly unusual for an installer to place icons in both the CommonDesktopDirectory and the current user's desktop. If new icons are in both locations, only delete those from the common desktop.
• Check that the target for each new icon is a subdirectory of the install location before deleting. For package installs for which the install location is not known, attempt a regex match of the $env:ChocolateyPackageName or the SoftwareName to the icon names.

You developers are smarter than I am, so I'm sure there are additional/better methods to handle this, but I would love to see this feature.

Thanks!

[FranklinYu]

I think it is easier and less intrusive to implement a global flag (set through config) and provide package maintainer some PowerShell helper to query user preference. This is less enforcing, but it will guarantee to work if package maintainer implements it in chocolateyInstall.ps1.

[teknowledgist]

This is less enforcing, but it will guarantee to work if package maintainer implements it in chocolateyInstall.ps1.

The limitation of that is it relies on the package maintainers. My interest in this is to give control to the installer, regardless of the maintainer's willingness/interest/ability to implement anything.

[baryluk]

Apps putting shortcuts on desktop or in menu bar drives me nuts on Windows. Please support global switch to prevent them from doing this by default. Only desktop icon I have is Firefox. That is all.

[lguerard]

Hi guys, sorry for digging up this issue but is there any news on this ?

[bcurran3]

Not related, but related: https://github.com/chocolatey/choco/issues/1185 ^^^^ If the above got implemented, this issue could be handled by a post run helper.

[eyalroz]

Just to clarify the relation of my issue #2016 and issue #344 to this one:

There are (at least) four kinds of icons/shortcuts:

1. Desktop
2. Start Menu
3. Explorer Context Menu
4. Send To menu

and there are (at least) three policies w.r.t. adding these shortcuts:

1. Always add them
2. Never add them
3. Add them on installation, but not on update

and these policies can be set at:

1. Package scope
2. System (chocolatey) scope

Now, here's what these issues ask for:

Issue	Kind of shortcut	Requested policy	Policy scope
#4 (this one)	1	2	2
#344	1	2	1
#344	1	3	1
#2016	2	3	2

[jaanli]

Seconded. Homebrew supports this, and would make user's desktops a lot cleaner :)

[shaneholloman]

+1

[Tyrand]

where update

[eyalroz]

With the time I've spent so far in life moving and deleting desktop and start menu icons on Windows systems running chocolatey, I should probably have just taught myself C# and coded a fix for this :-(

(of course that's partly because Windows asks for confirmation for almost every one of these movements)

[gep13]

@Tyrand @eyalroz have you taken a look at the linked issue:

https://github.com/chocolatey/choco/issues/1185

There is a PR associated with that issue, and once merged, opens up the possibility of doing exactly what is requested in this issue, as well as many other things.

[eyalroz]

@gep13 : Pre/post install hooks could indeed be an avenue for implementing this; but the implementation would still be non-trivial. The most naive approach would be, before an installation, to record all existing shortcuts (desktop, start menu etc.); then, after installation, record existing shortcuts again, and delete the set difference of After \ Before.

Also... issue #1185 is from 2017 and PR #2535 is from January, so I'm not holding my breath...

[pauby]

This functionality now exists using package hooks, specifically using this package which is currently in alpha (requesting feedback).

I'm going to go ahead and close this now, but we can always reopen if necessary.

[eyalroz]

@pauby : Can you explain how this is supposed to work? The term "package hooks" suggests one has to do something for each package. Also, the request is for something that is enabled, or at least configurable, by default, without users having to locate some package hook on the community website.

Finally, reading the package hooks documentation, it says:

A feature is available in Chocolatey CLI v1.2.0,

i.e. not a feature available in the GUI. Since most users (IFAICT) use the GUI, this bug should not be closed before the GUI offers this option.

[TheCakeIsNaOH]

@eyalroz there is some documentation here: https://docs.chocolatey.org/en-us/features/hook

Also, the request is for something that is enabled, or at least configurable, by default, without users having to locate some package hook on the community website.

To expand/clarify what @pauby was saying, this feature is not something that the Chocolatey team wants to put into Chocolatey CLI itself. Instead, it is a feature that is now provided by a hook package.

i.e. not a feature available in the GUI. Since most users (IFAICT) use the GUI, this bug should not be closed before the GUI offers this option.

A feature being available in a version of Chocolatey CLI does not necessarily mean that it is available or not available in Chocolatey GUI. This is because Chocolatey GUI is built on top of much of the same code that Chocolatey CLI has.

As far as I am aware, hooks should be working in the most recent version of Chocolatey GUI.

Even if they were not, then an issue should be opened at the Chocolatey GUI repository, not in this repository.

[eyalroz]

To expand/clarify what @pauby was saying, this feature is not something that the Chocolatey team wants to put into Chocolatey CLI itself. Instead, it is a feature that is now provided by a hook package.

@pauby didn't actually say that. And - why would he? The current state of affairs is a painful mis-feature experienced by all users. Surely the team wants to fix it, right? ... in fact, once the support is added, the next logical step is #2016 , with create-icons-just-once enabled by default.

As far as I am aware, hooks should be working in the most recent version of Chocolatey GUI.

The GUI doesn't mention hooks anywhere that I can find...

Even if they were not, then an issue should be opened at the Chocolatey GUI repository, not in this repository.

Ah, but if the GUI doesn't easily support using hooks, than fixing this bug only via a hook means fixing it in an even more fragile sense than for the CLI.

[pauby]

@pauby didn't actually say that.

I didn't explicitly say that, no. I did say that the functionality was offered in another feature, closed the issues and added the label that has 'Not Implementing' in it. Apologies if that wasn't clear.

And - why would he? The current state of affairs is a painful mis-feature experienced by all users.

I take issue with that. A few users want to stop desktop icons being added. Not all. And I'd challenge you on it being painful. Irritating, perhaps. But that's all relative.

Surely the team wants to fix it, right?

I don't agree that the place to stop icons being added to the desktop is within a package manager. The job of a package manager is to manage packages. It's the package's job to manage the software.

I've discussed this a few times elsewhere.

The GUI doesn't mention hooks anywhere that I can find...

Chocolatey GUI is a GUI that works with Chocolatey CLI. The implementation of hook scripts is within Chocolatey CLI.

[eyalroz]

I take issue with that. A few users want to stop desktop icons being added. Not all. And I'd challenge you on it being painful. Irritating, perhaps. But that's all relative.

The "few" users are basically all users who ever voted for a bug here on Bugzilla, i.e. the involved users. And for the past

Has the project actually gotten feedback from users saying that it's important for them to recreate the icons on each update? This bug has existed for 7 years, and there has not been a single comment here suggesting that repeated icon regeneration is desirable. I'm actually quite surprised by a project developer suddenly adopting this position.

Surely the team wants to fix it, right?

I don't agree that the place to stop icons being added to the desktop is within a package manager. The job of a package manager is to manage packages. It's the package's job to manage the software.

Let's start by saying that you are making an excuse. This is a serious problem for all, or almost all, your users, which has been neglected for years.

However - let's adopt this attitude for a moment. You could define the re-installation of icons on update as a package bug, for every one of the 10,000 packages - but that would only be meaningful together with an ultimatum to resolve the bug within X days or have the package barred from installing. That's not the path I would choose, but if you want to lay responsibility fully with the package manager - do that. And I mean today, not in 7 more years.

The appropriate solution - a matter of essential consensus until your puzzling comment - is for chocolatey to handle this situation, as a fallback. It is, in fact, the job of a software distribution's maintainers - with the support of the package management system - to manage "package transgressions" insomuch as they degrade user experience or clash with user behavior or other packages. For example, Debian's dpkg, upon finding that the user has edited a file a package update wants to change, offers a mechanism for examining the changes, choosing what to keep etc. And Debian's maintainers provide other support mechanisms such as "alternatives" which handles installation path clashes through symbolic links etc.

On Windows, Microsoft does not manage much software, and chocolatey must pick up the slack, which is admittedly more of a challenge. But that only means that the solution chocolatey offers may not be 100% perfect; or that it would take some time to develop - it doesn't mean you can just shrug this away.

I've discussed this a few times elsewhere.

It's strange that it was not discussed on the bug page(s) where this was requested. But - can we have a link please?

[pauby]

Has the project actually gotten feedback from users saying that it's important for them to recreate the icons on each update?

We use GitHub (here) for people to provide feedback.

We are not implementing this functionality in Chocolatey CLI at this time. Depending on your use case, as I said above., it can be facilitated by hook scripts.