Modern System Tray Icon

[mveril]

Proposal: Modern System Tray Icon

Summary

After a feature proposal to the WinUI team to make system tray icons with WInUI microsoft/microsoft-ui-xaml#2020 and to have followed this discussion #519 and this proposal #711 I would like to offer my take on what the modern way to create system tray icons should look like. A system-managed tray icon accessible for UWP and WIn32 applications respecting the app lifecycle #111 and offering a UI that respects WinUI standards.
We also must take into account that many applications that use the system tray APIs are "service-like" app (that needs 24/7 execution), and so the App Lifecycle API are not suitable in this precise case. The new APIs need to be easy to use on each case.

Rationale

• The system tray icons are not dead and still used a lot.
• A refresh of the UI is necessary to follow the system theme (not the application theme in this case) and to use WinUI for example for the context menu. (Like the One drive system tray icon).
• The actual System tray API needs an app that runs all the time but the management of the context menu and user actions can be handled by the system and through background tasks and app activations.

Scope

Capability	Priority
This proposal will allow UWP and Win32 developers to create System tray icon even if the app respect the app lifecycle	Must
This proposal will allow developers of Win32 "service-like" app that don't follow the standard lifecycle to create System tray icon	Must
This proposal will allow UWP and Win32 developers to create System tray icon that respect Windows theme and fluent design	Must
This proposal will allow UWP and Win32 developers to interact with the System tray icon from background and foreground	Must
This proposal will allow UWP and Win32 developers to launch his app using his System tray icon	Must
This proposal will allow UWP and Win32 developers to easily show context menu flyouts associated to the system tray icon	Must
This proposal will allow end users to run background tasks using the system tray icon	Must
This proposal will allow end users of a service-like Win32 app to interact directly with the service using the system tray icon	Must
This proposal will allow end users to interact with the system tray icon using keyboard	Must
This proposal will allow developers of Win32 "service-like" app to create System tray icon with the same set of APIs	Should
This proposal will allow UWP and Win32 developers to easily show custom flyouts associated to the system tray icon	Should
This proposal will allow allow end users to easily interact with the System tray icons using keyboard	Should
This proposal will allow end users to control background tasks using the system tray icon	Could
This proposal will allow UWP and Win32 developers to show balloon notifications	Won't

Important Notes

APIs that could be inspiring

• The ToastButton API could be an inspiration for the context menu item even if checkbox context menu item and radio context menu item could be supported

• The ContactPanel API could be a good inspiration for the system tray flyouts.

Open Questions

How the new APIs that will be adapted to short-running applications could also be adapted to long running "service-like" apps ?

[orcmid]

As an user, I find the increasing use of system tray icons and keeping apps running in the background to be quite offensive. In particular, too many apps force going to the system tray on close with no user control of the behavior.

1. Zoom on Windows 10 does it better - it ends up creating a task bar icon that reveals Zoom is still running, and while objectionable, it is easy to notice and to exit it.
2. My Philips DreamWeaver data card loader, an app I only run once a week, goes to the system tray whether I like it or not (although there is a notification that happened). Then I Have to go kill it. There is absolutely no reason for this application to stay running in the background. And I still use the removable drive removal to ensure that the USB key from my C-PAP can be safely removed.
3. The change of the Bing Desktop App to just be a Bing Wallpaper app that sits in the system tray is very annoying. That is the only way, now, to find out what the wallpaper image subject is and where to find more information about it. That's a tiny symbol and I have to perform extra work. It keeps me from doing more Bing searches every day. I doubt that shows up in their stats, but I use Bing search less than before.
4. The Discord app is another offender. I learn that I have left it running by virtue of all the notifications that pop up, until I go into the system tray pop-up and kill it dead.
5. What makes this even more difficult is apparent absence of a way to force certain apps to have their system tray icon be visible and not hidden in the pop=up of all of them. I made good use of that provision in the past. I can't find it on the currently-supported Windows 10 releases.

[ptorr-msft]

@orcmid presumably a new API would solve those problems:

1. Users must grant permission for the icon to exist, with a mechanism to manage them after-the-fact, too.
2. The target app is suspended / terminated, and only woken up when the user interacts with the icon.

[mveril]

@orcmid presumably a new API would solve those problems:

Yes I think

1. Users must grant permission for the icon to exist, with a mechanism to manage them after-the-fact, too.

Yes but I don't know if Win32 apps should be allowed to enable it by default like startup tasks or not

2. The target app is suspended / terminated, and only woken up when the user interacts with the icon.

Exactly It's the main interest of this proposal. It's what I called "respect the app lifecycle"

[huoyaoyuan]

System tray icon can also (and commonly) be used for an interface to service-like applications. The application runs background tasks and the icon is active.

[orcmid]

System tray icon can also (and commonly) be used for an interface to service-like applications. The application runs background tasks and the icon is active.

Yes, and I see those. They are not the subject of my complaint.

I am a little bemused that I am not explicitly running any graphical programs but 15 are using my GTX 1060 6GB display adapter. That's an usefull systrap thingie. I am also happy with my password monitor and HyperSnap being there and on the displayed system tray.

I am about to uninstall Skype since most of those calls are now accomplished with Microsoft Teams. Neither Teams nor the "Your Phone" app seem to need residence on the system tray.

I am not so thrilled with Outlook, OneNote, and WinZip taking system folder real-estate though. I'm going to dump the Wnzip and Outlook ones.

[riverar]

The target app is suspended / terminated, and only woken up when the user interacts with the icon.

Our app consists of a flyout that appears when a user clicks a notification area icon. We cannot afford to be suspended and resumed, it must remain running in the background. Because this proposal requires apps to participate in process lifetime management (PLM) without consideration of apps like ours, I must reject this proposal.

[ptorr-msft]

@riverar remember this is Reunion - it's all about options. I should have been clearer in my reply.

The actual requirement listed above is:

This proposal will allow UWP and Win32 developers to create System tray icon that respect the app lifecylce

"respect[ing] app lifecycle" means the app might suspend (if it wants to) or it might not. The problem with Shell_NotifyIcon today is that the app MUST keep running to check window messages; that's a poor design if your app doesn't need to be running 24x7.

[riverar]

@ptorr-msft Hm, I don't agree. @mveril states in their summary (emphasis mine):

A system-managed tray icon accessible for UWP and WIn32 [sic] applications respecting the app lifecycle #111 and offering a UI that respects WinUI standards.

The author further lists the following as a Must:

This proposal will allow UWP and Win32 developers to create System tray icon that respect the app lifecylce [sic]

While the author wrote "will allow", I believe that is in error. It appears the author's intention is to require apps to participate in PLM to take advantage of the proposed enhancements. I don't think that's fair to apps, like ours, that cannot participate in PLM.

Suggested scope changes:

- This proposal will allow UWP and Win32 developers to create System tray icon that respect the app lifecylce | Must
+ New mechanism provides facility for apps participating in PLM to create a modern Notification Area icon | Must
+ New mechanism provides facility for apps not participating in PLM to create a modern Notification Area icon | Must

[ptorr-msft]

If you read the spec for #111, nothing about suspension is mandated. It talks about "allowing" apps to be "notified" which implies they can choose to ignore the notification (or not even register for it). There is no forced "lifecycle" in Reunion, so if @mveril wants this proposal to require suspension, then a different change would be needed to the requirements.

(Direct quote from #111):

All of these are simply informative notifications: the app can do whatever it likes with the information

[mveril]

@riverar Sorry I haven't had time to test your app yet, but if I understand your needs correctly, IMHO it won't be necessary to have an always-on app to display a flyout on click. I don't know if you've paid attention to this but this proposal will allow support for flyouts with an API that might look like the Contact panel.
I understand that a lot of apps can't comply with PLM. (Docker, Antivirus and many more ...). You're right, more flexibility is always better, this is "Project Reunion" after all!
@ptorr-msft I don't think suspension is needed. after all, suspension is not needed for JumpList. Can you explain your thinking please. I agree with @riverar that the change he propose is needed in the scope. But for clarification what is the definition of PLM ? It's the same as the Reunion app lifecycle or there are some specificity?
So what would you imagine from an implementation perspective? Some APIs for app which support PLM with Background tasks and activation events and an alternative in the form of classical events to leave the choice, like the Window class of WinUI which supports both CoreWindow and HWind with certain APIs which are different for each case, or will a single API surface be possible to handle both cases?

[mveril]

@riverar I finally had the time to test your application (very good job ! I think I'll keep it on my system). Here is my conclusion:

Our app consists of a flyout that appears when a user clicks a notification area icon. [...] it must remain running in the background.

With this proposal, it will not be necessary (but must be possible) to have an application always active to display a flyout on click. This functionality should be handled by this proposal (because It is widely used) and the flyout would be created for you. Your job would only be to define the content of the flyout and adjust the size of it.
This corresponds to the scope:

This proposal will allow developers to show flyout using the system tray Icon

But in your particular case even if I have no certainty I think that you will still need an always active application to manage the global hot keys but that should absolutely not prevent you from using this feature proposal properly.