Add start menu entries for portable applications

[scottwillmoore]

Description of the new feature / enhancement

As discussed in this thread, portable applications now have a specification which enables standalone executables to be installed and added to the PATH. However, it would also be nice if there was an option to allow start menu shortcuts to be created for these applications.

Proposed technical implementation details

The implementation would be pretty similar to how portable applications are added to the PATH, except instead of a symlink a shortcut will be created with a title as specified by the manifest, and placed at %ProgramData%\Microsoft\Windows\Start Menu\Programs for machine installations or %AppData%\Microsoft\Windows\Start Menu\Programs for user installations. It might be a good idea in order to avoid conflicts to place shortcuts in a subfolder such as ..\WinGet.

[denelon]

We should look at arguments and settings for this particular scenario as well. Some command-line applications fail to run if they are executed without any arguments. For those applications, it doesn't necessarily make sense to have an icon. As stated in the linked thread, many portable applications with a GUI do make sense.

Users should be able to specify in settings if they want an icon or not. The default behavior should be specified by adding a value in the manifest, but settings or an argument would override.

[Trenly]

The default behavior should be specified by adding a value in the manifest, but settings or an argument would override.

I would propose adding a DesktopIcon and StartMenuEntry InstallerSwitch, as some installers (of all types) allow you to specify whether or not to create the desktop icon. Of course, since this isn't standard between publishers, sometimes the switch enables and sometimes it disables.

Proposal:

InstallerSwitches: 
  Silent: 
  |
  Upgrade: 
  DesktopIcon:
    SwitchValue:  <value>
    SwitchMode:  <enable/disable>
  StartMenuEntry:
    SwitchValue:  <value>
    SwitchMode:  <enable/disable>

This would allow for the arguments --desktop-icon [true/false] and --start-menu-entry [true/false] which could also be controlled through user preference settings

For portable apps, if the SwitchMode is enable, it will add it to the desktop/startMenu, otherwise it will not, and the arguments and user preference would override

[wmstack]

Also allow those to be configured in the install sub-command for Winget, so that while those could be defaults, e.g., the user can have flags to enable or disable desktop icons, if he doesn't want them, or for example, if there was oversight by the package maintainers that made it so the packages didn't include a desktop icon or start menu entry when it was needed.

[upintheairsheep]

We should look at arguments and settings for this particular scenario as well. Some command-line applications fail to run if they are executed without any arguments. For those applications, it doesn't necessarily make sense to have an icon. As stated in the linked thread, many portable applications with a GUI do make sense.

Users should be able to specify in settings if they want an icon or not. The default behavior should be specified by adding a value in the manifest, but settings or an argument would override.

We could automate this by opening each in an action runner, and if it closes in less than a second, it does not get added, and if otherwise, it does.

[upintheairsheep]

We should look at arguments and settings for this particular scenario as well. Some command-line applications fail to run if they are executed without any arguments. For those applications, it doesn't necessarily make sense to have an icon. As stated in the linked thread, many portable applications with a GUI do make sense.

Users should be able to specify in settings if they want an icon or not. The default behavior should be specified by adding a value in the manifest, but settings or an argument would override.

I know, that should be a manifest flag, and a bot can go through every portable WinGet package and open each app, and if it stays for more than 3 seconds, it’s a start menu app, then it closes it, repeat.

[upintheairsheep]

The default behavior should be specified by adding a value in the manifest, but settings or an argument would override.

I would propose adding a DesktopIcon and StartMenuEntry InstallerSwitch, as some installers (of all types) allow you to specify whether or not to create the desktop icon. Of course, since this isn't standard between publishers, sometimes the switch enables and sometimes it disables.

Proposal:

InstallerSwitches: 
  Silent: 
  |
  Upgrade: 
  DesktopIcon:
    SwitchValue:  <value>
    SwitchMode:  <enable/disable>
  StartMenuEntry:
    SwitchValue:  <value>
    SwitchMode:  <enable/disable>

This would allow for the arguments --desktop-icon [true/false] and --start-menu-entry [true/false] which could also be controlled through user preference settings

For portable apps, if the SwitchMode is enable, it will add it to the desktop/startMenu, otherwise it will not, and the arguments and user preference would override

I dont the desktop icon should be a seperate option, as desktops usually get cluttered or the user has to manually delete the shortcuts.

[superusercode]

The way scoop handles defining shortcuts in manifests is pretty simplistic:

    "shortcuts": [
        [
            "sil.exe",
            "Sil"
        ],
        [
            "Sil 1.3 Manual.pdf",
            "Sil Manual"
        ]
    ],

https://github.com/Calinou/scoop-games/blob/master/bucket/sil.json
Those files you see in quotes are at the root dir of the portable app, and you can use / slashes to navigate if they're in a directory.

I do hope this feature gets moved up since it's very important to enabling GUI apps that are distributed by zip without installers.

edit: I should add that the "Scoop Apps" folder is always in the Start Menu - it can't be moved - so for the majority of people it "just works" as is.

[upintheairsheep]

@Trenly this looks like a simple issue to do, and the lack of this is annoying many users around the globe.

[denelon]

@upintheairsheep,

Looks can be deceiving, and @Trenly doesn't work at Microsoft. You can see how we prioritize work and this Issue doesn't have as much "obvious" (by count of 👍) support as many other community requests. Please be mindful of our Code of Conduct.

[Trenly]

I would also say this issue may not be as simple as it seems on it's face. There are a lot of questions to be answered such as

• Where in the manifest do start menu entries go?
• What is the data format for start menu entries in the manifest?
• How would users obtain the start menu entries?
  • Would they be opt-in or opt-out?
  • How would upgrades be handled to respect user intent from the initial installation?
  • Are any new user settings required?
  • Would the start menu entry go directly to the exe or should it go to the symlink?
• Are there any technical differences between systems that could impact how start menu entries are created?
• How would start menu folders be handled?
• How would validation be handled?
  • If an app does not spawn a UI, should start menu entries be allowed?
  • Will validation pipelines need to validate the app starts when called from CLI and from the start menu entry?

In all reality, this is a feature that will likely need to be Spec'd out (see https://github.com/microsoft/winget-cli/blob/master/CONTRIBUTING.md#to-spec-or-not-to-spec).

[User486375]

As @superusercode already stated, this is not all too complex. All you need is to not have manifest maintainers add shortcuts for CLI or non-portable applications and state as much like scoop already does (everything in scoop is portable with default buckets). Or just have the maintainers define each portable application as portable or portable-CLI.

Scoop uses start menu entries pointing to a /current/ symlink of the latest version folder.