[ENHANCEMENT] Allow manually set undesired desktop links and update link removal behavior

[helltraitor]

Please confirm these before moving forward.

• I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
• This improvement refers to an existing feature. If you want to suggest a new feature, please use this template.
• This improvement is not a bug. If you want to report a bug, please use this template.

Describe the improvement

Currently, UniGetUI somehow detects links on desktop, but here is some examples, when it doesn't or doesn't supposed to:

1. Some applications may change desktop application name (e.g. Zen Browser become Zen recently)
2. Some applications are ignored in UniGetUI (discord and other electron and tauri based applications)

I would like to have an ability to manually set undesired links in desktop.

About link removal:
Can it be run after the last update of group? For example, when I updates two application, I want to removal to be running after the last update of those two. I can't say was it already running in the same situations, but this will allow to detect and remove links that may come in other time (not when updating, I mean)

Describe how this improvement could help users

As for me, I don't want to have any links in my desktop, that was created automatically (some browsers may create links as developers wish - really annoying)

For any decision that you will accept (include closing this issue) - Thanks for this application, It became really handy for me

[marticliment]

I would like to have an ability to manually set undesired links in desktop.

Since the last beta, you can perform a "Manual Scan", to add old shortcuts. Is that what you are looking for?

• Some applications may change desktop application name (e.g. Zen Browser become Zen recently)

This should still be catched by UniGetUI, you should be prompted about a new shortcut being detected

Some applications are ignored in UniGetUI (discord and other electron and tauri based applications)

How/where are their shortcuts being stored?

[mrixner]

Some applications may change desktop application name (e.g. Zen Browser become Zen recently)

If you're asking about not attempting to delete changed-name shortcuts, this is not possible as they're detected from the desktop folder, not on a by-package basis. If you're talking about marking them to be deleted, as Martí already said, they should be if they were added during a UniGetUI-sourced operation.

About link removal:
Can it be run after the last update of group? For example, when I updates two application, I want to removal to be running after the last update of those two. I can't say was it already running in the same situations, but this will allow to detect and remove links that may come in other time (not when updating, I mean)

What do you mean? UniGetUI should ask you to delete shortcuts only after all current (UniGetUI-began) processes are completed and it does so each time an operation set is completed. Perhaps you are referring to the current behavior of the remover, as mentioned below, which may be fixed by #3338?

Some applications are ignored in UniGetUI (discord and other electron and tauri based applications)

How/where are their shortcuts being stored?

I would be interested in this as well. As far as I was aware, the only shortcuts placed on the Windows desktop can be found in "C:\Users_{user}_\Desktop" or "C:\Users\Public\Desktop", both of which are checked. In fact, my shortcuts list has a public desktop shortcut, the UniGetUI one.

If you are unsure how to check the location, you can right click the shortcut, click "more options" (or whatever the equivalent is, I disabled the modern context over a year ago), and select "Copy as path"

However, as UniGetUI detected Discord for me, I suspect what you're encountering is fixed by the new "manual scan" button. UniGetUI doesn't automatically delete any desktop shortcuts located on the desktop at the moment (however, you might be interested in #3338). The only ones it asks you if you want to delete are shortcuts that were not on the desktop before the update operation completes and were added by said update operation.

As for me, I don't want to have any links in my desktop, that was created automatically (some browsers may create links as developers wish - really annoying)

I agree! #3338 should fix this.

---

Martí - in testing Discord, I noticed it doesn't ask about shortcuts added during an install process. I feel like I was going to do this when I originally implemented the feature - I think I was going to move the check code to the AbstractOperation class? Is there a reason this didn't happen, or did I just forget to do it, and if no reason could I do this now?

[marticliment]

I think I was going to move the check code to the AbstractOperation class? Is there a reason this didn't happen, or did I just forget to do it, and if no reason could I do this now?

The code is on OperationControl, but it is called when the OperationFinished event is triggered (see OperationControl.cs::OnOperationFinished(object? sender, EventArgs e)). The check should be called after the last running operation finishes, no matter what type is it, nor its finish state (success/failure)

[mrixner]

I think I was going to move the check code to the AbstractOperation class? Is there a reason this didn't happen, or did I just forget to do it, and if no reason could I do this now?

The code is on OperationControl, but it is called when the OperationFinished event is triggered (see OperationControl.cs::OnOperationFinished(object? sender, EventArgs e)). The check should be called after the last running operation finishes, no matter what type is it, nor its finish state (success/failure)

Ohhhhh, I think the issue is actually that Discord launches a separate installer process that creates the desktop shortcut, but it does so after Winget, and thus UniGetUI thinks it's done. Thank you for clarifying!

[helltraitor]

However, as UniGetUI detected Discord for me, I suspect what you're encountering is fixed by the new "manual scan" button. UniGetUI doesn't automatically delete any desktop shortcuts located on the desktop at the moment (however, you might be interested in #3338). The only ones it asks you if you want to delete are shortcuts that were not on the desktop before the update operation completes and were added by said update operation.

I've tried beta release - much better. I suggest to allow user to add links manually (since remove all shortcut maybe undesired, but probably I will use it and keep shortcuts in startmenu or elsewhere). So I think, you can close this issue if you will not add manual select.

Note: Manual select seems to be fine, but I don't know maybe some edge cases are not covered.

Thanks for mention beta

[marticliment]

Next version will have this issues fixed.