Bug 436506

Summary:	System Tray items for apps running in the background are mostly obsolete and redundant when the user is using an Icons-Only Task Manager
Product:	[Plasma] plasmashell	Reporter:	Podagric <kde.podagric>
Component:	System Tray widget	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	kde, materka, nate
Priority:	NOR	Keywords:	usability
Version First Reported In:	5.21.4
Target Milestone:	1.0
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Podagric 2021-05-03 01:20:52 UTC

Programs that can keep running in the background usually have an option to display some icon in the systray, but if the user prefers to hide the icon so that it is not always visible, taking up space and filling this area with different things, there will be no indicator (other than the hidden icon) that the program is active.

This is also, in my humble opinion, a matter of consistency. Because it prevents the systray from getting polluted with program icons that are already in the apps panel. And these icons often have nothing to do with the default icons of the Breeze theme, which only makes the situation worse (the screenshots I will put right below demonstrate this).

It also maintains a consistency as to the organization and separation of native plasma widgets from the systray and other user programs. Because it keeps the systray clean and dedicated to its primary purpose: displaying system information.

This is a big discussion, and some desktops have even completely removed support for program icons in the systray, I am very much against this, but I think it can be improved with a few tweaks.

Take this screenshot example (https://i.imgur.com/tTFzIdq.png), all six of these programs highlighted with the red line are currently active, but I don't have any visual feedback on this. They can display an icon in the systray, but this would turn it into a completely messy kitchen, besides duplicating the display of the same icons and taking up unnecessary space.

This is what happens if I choose to display the icons in the systray: https://i.imgur.com/c29IS0k.png
A total mess.

When everything is organized following basic criteria, this is the result: https://i.imgur.com/qrc7a9z.png
No duplicate icons and a much more objective notification area.

Of course there is an obvious option to simply disable the background running and not have this problem, but it would generate another one. Because they are tools that we usually need to keep running, but often not necessarily in the foreground, which brings us to the problem again.

To sum it all up: an indicator on the app icon telling that it is open in the background removes the need to have the same icon in the systray and keeps everything more organized and consistent. Apps where apps should be, and widgets where widgets should be.

Please don't get me wrong, I'm not criticizing the work of amazing volunteers, but rather suggesting a possible solution to one of the things that bothers me the most.

Comment 1 Nate Graham 2021-05-03 20:35:21 UTC

IMO the concept of a "System Tray item" for an app running in the background is a historical relic of the time before everyone uses Icons-Only Task Managers (or the equivalent.

Before Windows 7, running more than a few apps at once caused the Vista and earlier Taskbar to completely fill up with items that all became unreadable. Thus, System Tray items were invented as a way for apps to remain running with some kind of visible UI without taking up space in the main section of the Taskbar

Before Mac OS X with its Dock (essentially an Icons-Only Task Manager), there was no visible-by-default indicator of running programs at all; it was assumed that programs would all have a visible window. Once programs started to violate this expectation, System Tray items were, again, invented as a way for apps to remain running with some kind of visible UI.

Same thing with Plasma, which uses a traditional Windows-Vista-and-earlier style Task Manager until Plasma 5.20

But then a funny thing happened. The whole world moved to Icons-Only-Task Managers. First macOS in 2000, then Windows in 2009, and then Plasma in 2020.

What impact do Icons-Only Task Managers have on this problem? Well, as long as the windowless-open-in-the-background app is pinned, keeping it open without a window takes up no additional space at all. If it's not pinned, it takes up a small amount of extra space, not a big amount--and this is generally fine because every other app--open or closed--also takes up only a small amount of space. So for these apps, you can safely turn off their System Tray icons because you can use the main UI of the Task Manager to see if they are open or not and to show their window if you want.

Thus, I will argue that the Icons-Only Task Manager has rendered traditional app-specific System Tray items mostly obsolete. I have them all turned off, personally.

...Except for a few: system service type tray items, such as the Dropbox icon, Keepassx icon, and so on. IMO these are actually more like your system's built in tray items so they are right at home there, no need to hide them.

Comment 2 Nate Graham 2021-05-03 20:38:58 UTC

Now, how can we make this more automatic?

Perhaps we could detect when the user is using an Icons-Only Task Manager and suppress the SNI as long as the app is already visible in the Task Manager, because the app being running and visible in the Task Manager is already evidence enough. Or badge it something, as you suggest. Or just suppress it entirely.

None of these things may be technically feasible; just throwing ideas out there. Either way, moving to the System Tray component.

Comment 3 Podagric 2021-05-04 22:20:14 UTC

Thanks for the great history lesson on desktops, Nate. It really is a necessary step for a discussion like this.

Well, I have never used what mac, but it seems that it can "solve" this problem by filling the dock with many applications, and the user ends up pinning several programs to it.

I still think my discussion is more towards the panel side of the plasma, rather than the systray. Because as I showed in the screenshots, there is no visual feedback to the user that that program is running in the background. So the user has to use the icons in the systray to get this advice. 

Anyway, maybe it really is a technically difficult task, and this area is not one that I can help with, but the discussion will be logged in case someone wants to take the lead on this and try to solve it in some way.

Comment 4 Konrad Materka 2021-05-05 20:26:17 UTC

Hmm, I think Unity had it implement this way. That's why there is no support for left click in libappindicator - it was never used because left click was reserved for task manager. I'm not sure, maybe it still works this way in Gnome on current Ubuntu?

Comment 5 Nate Graham 2021-05-05 21:21:02 UTC

Not sure about Ubuntu's GNOME flavor, but stock GNOME has no out-of-the-box support for 3rd-party tray items at all IIRC.

Comment 6 David Edmundson 2021-05-05 22:00:28 UTC

>Hmm, I think Unity had it implement this way.

No, they were the same as ours, they just always foregrounded a window on left click. 

As for merging with task manager icons, I'm pretty sure it's been tried in the past as a POC. It's something that works in some cases, but not in others and you don't really have enough metadata to tell those two apart. Sometimes the SNI has a different cardinality or presents something different in the icon, sometimes it 's just duplicate telling us nothing. 

But duplication is better than breaking things.

I think trying to magically change outside of the client's expectation is a bad direction. If a client asks for a system tray, we should give them one.

What we can do is promote use of the badge API for badges and encourage a phase out in applications. We currently already support badges in our taskmanager and it is what Ubuntu used to use for their sidebar.

Comment 7 David Edmundson 2021-05-05 22:01:10 UTC

I don't think this makes for a particularly useful open bug ticket as it is not directly actionable.