Windows 10 toast notifications from Winget

[Karl-WE]

Description of the new feature/enhancement

it would be pretty cool to have winget integrated with Windows notifcations / toasts

Proposed technical implementation details (optional)

this script shows how easy it seems to create a notification with a customizable input https://gist.github.com/dend/5ae8a70678e3a35d02ecd39c12f99110

notification for user when install / update was successful or failed

Note: This might raise expectations that winget is able to execute install without local user admin rights because in terms of automation it would make no sense to have notifications for things running via scripts (startup / shutdown at system level)

[denelon]

@Karl-WE I like this as an enhancement. I'll also make sure we add settings so a user may enable or disable notifications.

[Trollwut]

is there any update on this topic?

[shawngmc]

I was just thinking about this a day or two ago when I realized I hadn't updated anything installed this way in months.

I think such a feature could be implemented across a couple MVPs:

1. Simple toggle for notification that any updates are available.
2. Include update count.
3. Add click to run updates. (Knowing that it will require admin.)

Unfortunately, without this, winget-installed apps tend to get out of date easily:

• Unlike Linux, there is no automatic updates
• Unlike Linux, we don't get on a CLI nearly as often, and even if we there is no terminal notification (.bashrc equivalent).
• While some apps have their own internal update checking, MANY do not.

[denelon]

Today, there isn't a service running in the background to invoke winget upgrade to give users notifications for packages that could be updated. In the future, this is something that may change, and I am aware there are some open-source solutions that look for updates and run them in the background. I think adding a "setting" for WinGet to enable a toast when upgrades are detected, as well as when an install has completed, or an upgrade has completed.

We would also likely want both a setting and CLI arguments for "to toast" or "not to toast".

I might want to manually run winget upgrade --all --no-toast so I don't see all the notifications, or I might have the "no-toast" setting configurred, but I do want to get notified when it's completed so I could run it in a terminal tab and minimize it while I do my other work so I could be informed that it's completed. Maybe I don't want a toast per package, but I do want one for the overarching upgrade all flow...

[Karl-WE]

Forgive me this sidenote.

"to toast" or "not to toast", that is the question.

For once let's toast towards the new year and a wonderful future of Winget 🥳

On topic: is there anything else I could provide to this PR?

I agree one toast per package at upgrade all might be less useful as they would flood the notification area. Some might like this verbose information and know something happened others might feel bothered.

Are version upgrades indicating the previous version and new version stored in winget log? Is this log easily accessible via a winget command without using Explorer.

Then I would prefer to have one toast and refer to the logfile on upgrade of several packages and only toast on fresh installation or uninstallation when one package is handled, even when they are more than one but scripted or via Intune.

[shawngmc]

Today, there isn't a service running in the background to invoke winget upgrade to give users notifications for packages that could be updated. In the future, this is something that may change, and I am aware there are some open-source solutions that look for updates and run them in the background. I think adding a "setting" for WinGet to enable a toast when upgrades are detected, as well as when an install has completed, or an upgrade has completed.

So, as a hypothetical MVP, could we start with a CLI option that checks and pops a dialog box or a Windows notification saying there are app updates available? This could then be called via Windows Scheduled Tasks (cron equivalent). It does not need to be a discrete Windows service.

[Karl-WE]

Well I would prefer the idea of a service so we could install things in SYSTEM context. Scheduled task could be altered by a user or 3rd party "optimizers". Of course scheduled task is a simple way to implement this and would remove dependencies to the Windows Core team.

[shawngmc]

Well I would prefer the idea of a service so we could install things in SYSTEM context. Scheduled task could be altered by a user or 3rd party "optimizers". Of course scheduled task is a simple way to implement this and would remove dependencies to the Windows Core team.

I don't disagree here - Scheduled Tasks are alterable by a user. It gets into a philosophical discussion of how this compares to how this is done in other OSes:

• Android: The Play Store does this via a service (Google Play Services, if I remember correctly).
• Linux: Depends on the Distro/WM, but there is typically a WM-integrated service that interfaces with the package manager library (which is not a service!).
• Mac: I think the App Store also gets a system service.
• IOS: Not really sure offhand.

I guess the question also becomes what is in charge of the notifications:

• Windows Store doesn't make sense, you can't manage these packages through it.
• Winget, itself, is currently CLI only and not a service. If it directly handled the toast, it would add GUI and background app dependencies.
• A standalone windows service could work, but would that be a separate install? And how, exactly, would it interface with winget - by running CLI commands?

This actually leads to a bigger problem - is WinGet currently monolithic? It is one CLI tool, and as far as I know there is no API for another tool to interact with WinGet outside of CLI calls. For example, apt on debian distros has the libapt-pkg library, and it's in charge of maintaining the cache. Yum-compatible tools also have a standardized cache and use a lock to interface with it, but yum/dnf is not the only tooling, AFAIK.

As far as I can tell from a quick search, I don't see any ticket to add an API in the roadmap. #1753 deals with adding structured data output, which could be used by something calling the CLI to generate a toast or other GUI element, but I still get the feeling that this is not the best path forward unless WinGet is intended to stay monolithic.

@denelon, would you be able to provide some insight here? What are WinGet's planned dependencies - .NET, PowerShell, Windows Desktop, Windows Services, Windows Store (which could add some interface in theory)? Is there any possibility of separating the UI (WinGet CLI, a theoretical Windows Package Manager GUI) from the package management 'backend' code? Is there something here that already exists that could be tapped into?

[denelon]

We have already been working on a separate COM API via NuGet packages for system context. The CLI has a COM API available for other applications. The CLI has been gradually being refactored to call the COM API, and the PowerShell module also uses the COM API. The Microsoft Store calls the client COM API, and Intune calls the "in process" COM API available via NuGet which depends on WinGet (via App Installer) being installed.