Add plugin for system tray icons

[cbenhagen]

This is related to the menu plugin.

Needed not so obvious functionality:

• Position of the icon
• Setting icon as monochromatic template image is needed on macOS so it can support dark mode
• Allow text instead of the icon or in addition to the icon. I don't know if this is possible on Linux or Windows but macOS allows this.

@stuartmorgan should I create this issue in the flutter repo or is this the best place for it?

[stuartmorgan]

It's not clear to me how this is related to the menu plugin; the system tray and the application menu (if any) are entirely separate as far as I know. I'm also confused by the reference to macOS as there's no such thing as a system tray. Are you talking about changing the dock icon?

It would be helpful if you could clearly describe the functionality you want to be able to implement on each platform, perhaps with some representative screenshots (e.g., from other apps doing what you would like to do) for each platform.

[cbenhagen]

I guess macOS calls it the status menu. Such a plugin would add the icon. The menu plugin most likely would show the menu when you click the icon as it is the OS which provides the menu (at least on macOS). Here is an example on macOS:

Having the position of the icon would allow for custom menu windows to be displayed like so:

[stuartmorgan]

I guess macOS calls it the status menu

Apple fairly strongly discourages the use of the status menu, so I don't think that belongs in the core framework; see this description of the cases where plugins are currently hosted here.

A plugin to add a macOS status menu item seems like a good candidate for a community plugin rather than something temporarily hosted here. Is there a reason you think this needs to be part of the framework?

Having the position of the icon would allow for custom menu windows to be displayed like so:

Showing a custom window containing Flutter content isn't possible until multiple windows are supported (unless the app is only a status menu item, but that would require a very different runner template).

[cbenhagen]

In any desktop framework I have worked with so far this was part of the framework so I hoped to help adding this to my favorite one as well. Can you point me to where Apple discourages the use of the status menu? What about Microsoft and the KDE / GNOME projects?

Most system tray apps I know do only have that menu and maybe a settings window. So having only one window is not that much of a restriction. Being able to open more than one will definitely be appreciated on any Flutter Desktop app though.

[cbenhagen]

All I can find in Apples Human Interface Guidelines is this:
https://developer.apple.com/design/human-interface-guidelines/macos/extensions/menu-bar-extras

Some of Apples own tools like the Time Machine use the icon in the status menu plus a window as their main user interface. Also Apps like Dropbox make heavy use of the status menu.

[cbenhagen]

Also checking https://developer.apple.com/documentation/appkit/nsstatusitem does not look as its use is deprecated or discouraged in any way.

[stuartmorgan]

Can you point me to where Apple discourages the use of the status menu?

The Overview section of https://developer.apple.com/documentation/appkit/nsstatusbar, which is the API for it.

What about Microsoft and the KDE / GNOME projects?

I'm not sure; that would need more research. However, my limited experience suggests that most apps don't need to put things in the system tray; pointers to contrary information are welcome.

Some of Apples own tools like the Time Machine use the icon in the status menu plus a window as their main user interface. Also Apps like Dropbox make heavy use of the status menu.

I'm aware that applications that use the status menu exist. My question isn't "why should it be theoretically possible to add a status menu item?" but "why should this be a core part of the framework rather than a plugin?"

[stuartmorgan]

Also checking https://developer.apple.com/documentation/appkit/nsstatusitem does not look as its use is deprecated or discouraged in any way.

I don't know how to read:

Use status items sparingly and only if the alternatives (such as a Dock menu, preference pane, or status window) are not suitable.

other than as discouraging their use.

[cbenhagen]

That it should only be used if other options are not suitable implies that there are moments when its use is a perfectly valid option. But as we both agree that it should be possible to use them the only question remaining is if it should be part of the framework or not. I don't know what should be the criteria for that. Out of all the apps I wrote in the past years most use the system tray. But that is hardly an argument. All I can say is that to me it feels like it should be part of the framework and that it is in most of the ones I know. Feel free to close the issue if you think it should under no circumstances be part of the framework.

[ChaseLewis]

A large number of applications now for PC's run just in the background like Dropbox, VPN Clients, Alarm apps, slack, discord, applications that manage USB devices, etc.

Not supporting the system tray is basically discouraging all applications that do these operations and probably many more, as it would not support the basic required functionality for any of them. It is not a major exaggeration to say MOST applications have this requirement. Would seem short sighted to not include this. To be honest when looking at different cross platform solutions this has typically been my #1 requirement and unfortunately why I often have had to choose electron apps or we choose to release on only 1 platform for our projects.

So just seconding support for this feature.

[stuartmorgan]

It would be helpful if people requesting support for this could be clear about what platform(s) they are talking about. For instance, I'm running both Slack and Discord on macOS right now and neither of them are NSStatusItems. I currently have only one non-system app running that is a status item, and as someone whose primary background is macOS development I feel confident saying that it is definitely not the case that most macOS applications require status items.

There may well be substantial variation in expectations across platforms here though, and I'm much less familiar with Windows and Linux conventions.

Not supporting the system tray

Not having it bundled as part of the framework is not the same as "not supporting". Consider geolocation on mobile, for instance; I would expect that many mobile developers would claim that most mobile applications need it, but it's a third-party plugin in Flutter. If there were things preventing a plugin from implementing status bar support I would consider that a significant API issue.

[joeblew99]

so sounds like a community plugin is the way to go.

Anyone know if there is an awesome flutter desktop plugins list anywhere ?

[lesnitsky]

check out https://github.com/lesnitsky/flutter_desktop_plugins I have some plans about building tray related plugin, but not sure about timeline (depends on project requirements I'm working on)

…

On Wed, Oct 30, 2019, 1:49 PM jow blew ***@***.***> wrote: so sounds like a community plugin is the way to go. Anyone know if there is an awesome flutter desktop plugins list anywhere ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#595?email_source=notifications&email_token=ABPYUNRRMUZGPCQDGJFYQKTQRFRBZA5CNFSM4JCLK6W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTWPWQ#issuecomment-547842010>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPYUNRPOOR6S372V6M7T7TQRFRBZANCNFSM4JCLK6WQ> .

[morsedev]

I think this should be part of the main framework, for me the system tray is the place to inform the user about the status of an app that runs on background, and frameworks, like electron, have this feature implemented as part of their main API. Currently I'm working on a desktop app using flutter for web + electron due to this system tray lack on flutter desktop

[esDotDev]

Yes I don't see any valid reason to not support this. Whether "most" apps use it or not, is not really possible to prove and besides the point anyways. I'd argue that it's a core functionality of the platform (desktop), and if you're going to run on that platform , and compete with the other solutions, you should support it.

[stuartmorgan]

Yes I don't see any valid reason to not support this.

Please re-read my previous responses; I've already explicitly addressed this. Nobody has suggested that it shouldn't be possible for Flutter apps to use the system tray.

In terms of productive things that could be done to move this forward:

• Building it as a plugin
  • Filing bugs for anything that makes this difficult or impossible to do as a plugin.
  • Providing specific technical feedback about things that would be easier to implement within the embedding/framework rather than a plugin.
• Providing use cases where a such a plugin, if it existed, would for some reason not be sufficient.

That would provide a lot more concrete information for a final decision. And if it's built as a plugin it could easily be folded into the framework later if that were the outcome, as the communication channels and implementation methods are the same either way.

Even if we decided right now that this should be part of the framework, there is a significant amount of higher-priority work on the roadmap right now, so either way the gating factor on the functionality being available is someone implementing it, not deciding where it should live.

[mrmcq2u]

Just for the record this is no longer supported by GNOME either,
There are different reasons for its removal, One example is that the user should be able able to visibly distinguish between system prompts and third party applications(otherwise potentially malicious applications could spoof the user by cloning the visual appearance of a system prompt).

Thus, system status area is reserved for the system and not third parties. In a future release when the user is prompted by the system they will see an icon in the system status area so allowing third parties to place whatever they want in there kind of breaks things from a security and trust perspective.

There are alternative integration points that developers can take advantage of though, and the alternatives will have other benefits(translate better to mobile than an overflowing unorganized tray).

I think it would make more sense to integrate something like this as a third party plugin.

[Pierozi]

I understand the argument that most of app don't need it, and that pollute the system menu.
But some of app need it, example on MacOs: Docker, IPFS, Nextcloud, Irvue, or allmost all password manager.

All sort of apps that does thing in the background and need minimal UI.
If someone start a community plugin, thanks to link it here as @lesnitsky have done.

[neontorrent]

Just for the record this is no longer supported by GNOME either,

GNOME doesn’t always make the best decisions. A lot of linux distros are actually dropping gnome and use KDE, or use their own version of gnome like mate.

[proninyaroslav]

A bit off topic: is it possible to programmatically hide or close a window, but still keep the process alive? This is similar to the hide()/show() methods in Qt and this is the standard approach in order to minimize the app to the tray.

[SteveCruise]

hope a "minimize to tray" feature for windows

[SvenDowideit]

https://github.com/JanezStupar/flutter_systray ?

[stuartmorgan]

From that project's page:

a plugin for go-flutter-desktop

That's a completely separate embedding from the official desktop embeddings, with its own (incompatible) plugin system.

[DevDorrejo]

how is going this for linux?

[stuartmorgan]

Closing, as at this point there are no plans to add new plugins to this (legacy) repository. The place to request the support for this in either the framework or a first-party plugin is the Flutter issue tracker.