We need to talk about the status icon :)

[allanday]

Status icons are fairly obsolete. There are various issues with them, and the guidance is to avoid them.

The notification role of status icons is better served by proper notifications, either through libnotify or GIO. The other role played by status icons is to allow an app to run without having a window open.

The current recommendation for how to replace this is:

• Have an application setting for "Run in the background" (could be a check box in the app menu)
• When run in the background is true, the app should be included in the autostart list and should continue to run when its window is closed
• Run in the background should default to off, but the app should prompt the user when they first close it, to ask if it should be turned on

In the future this behaviour will hopefully be supported by Flatpak and associated technologies.

[aperezdc]

@allanday: I am well aware of status icons in their XEmbed incantation to be obsolete, deprecated, not working in Wayland, and in general a terrible idea.

Nevertheless, some people may want to use them still, especially when running in DEs other than GNOME, and I would like to support these people. And even in GNOME. The TL;DR is that we do not have something like this built-in:

---

Now, for a longer discussion, keep reading...

There issue at hand is that in GNOME there is no way for an application to visually signify to the user that there is activity pending to be reviewed, in a way that can be noticed at a glance. Sure, GNotification is nice and all, and having persistent notifications is already an improvement over transient notifications which just pop and then disappear, but there is a host of issues which they do not address, or solve very poorly:

• If one didn't notice the notification, it is usually not immediately obvious that there are notifications pending to be read, and that one should click the clock on the top bar to check them.

• Sometimes a blue dot will appear next to the top bar clock, but most of the time it won't. Most users do not know under which circumstances it appears. Even people like me who used GNOME 3 since day one are flabbergasted that on the surface it behaves in an seemingly random way.

• Even if the blue dot appears, an user has no way of knowing which application is letting them know there, which prevents users deciding to check the notifications (or leaving them be for later) depending on the application. For example at one given time, I may want to check new e-mails right away if I am waiting for a reply.

There are a few extension for the Shell trying to alleviate the above issues, none of which provide a satisfactory solution (probably there are more, I onl did a quick search):

• Notifications Alert
• Active Notifications Indicator
• Message Notifier
• Usermenu Message Notifier
• Pidgin Persistent Notification

On top of these, there are others like Permanent Notifications which try to prevent the user from missing transient notifications. Many applications, in particular if they are still using libnotify, never emit persistent notifications, so this is sort of a band-aid solution.

Wrapping up, as an user, I would like GNOME to provide:

• A visual indication that there are notifications that I didn't interact with: either I didn't dismiss them (pressing the X button on their top-right corner), or didn't click on them, or were not withdrawn by the application which emitted them in the first place.

Then, both as an user and developer, I would like GNOME to provide:

• Visual indications that a particular application has “pending interactions” in non-intrusive manner (no bouncing animations, blinking colors, or the like). This should be controllable by the application (i.e. there is some API).
• (Optional) In case som kind of badge or control is shown around that the user can interact with, make it possible for the application to define possible actions. Different applications may want different behaviours: a chat application may want to show a popup menu with the list of unread conversations and allow to choose one item to directly present that one to the user; while an e-mail application may want a “Mark all read” option; or GNOME Calendar may want “Dismiss” and “Remind me tomorrow” options.

[MightyCreak]

Very nice analysis of the current status of the notifications in GNOME @aperezdc

I am also a bit mesmerized by the permanent and non-permanent notification. I don't think there should be a distinction there actually, all the notifications should be permanent until the user closes then. And some notifications might even be unclosable, for applications like music players, although it's not really a notification per se, but more of an externalization of the app UI.

I would add that GNoME might take some inspiration from Android. The top-right corner could stack the pending notifications, themselves grouped by applications.

Another important feature for the dev would be the possibility to remove a notification that's been sent (maybe it's already possible, IDK). For example, Dota uses the GNOME notification system and after a few hours of playing the game, I come back to the desktop and I have 10 notifications pending saying that my game is ready. In that case, first, notifications should be grouped and, second, once the game is started, the notification has absolutely no value, therefor the dev should be able to remove it.

[allanday]

We've had lengthy discussions about app launcher "badges" in the past, and for various reasons decided that they weren't something we wanted. One issue is that they can be very distracting. Another is that they are ambiguous - different apps use them for different things, which makes them unpredictable.

From a GNOME design perspective, notifications are the way to attract attention to application events. I think it's important to have a single API for this - if there are multiple mechanisms to achieve the same thing, the result is inconsistent behaviour by different applications.

I'd be happy to discuss how GNOME's notifications can be improved, although I don't think this thread is the best place to have that conversation. Likewise, while I'm sure there's room for improvement, I don't think there's anything so critical with GNOME's notification design that means that status icons are necessary. Status icons aren't permanently visible in GNOME, anyway.

[aperezdc]

@allanday: Yeah, I was already thinking that instead of continuing here with the discussion after the braindump it would probably be better to continue the conversation in Bugzilla or mailing lists. Let's catch up on #gnome-design and decide what to do.

[jaragunde]

The notification role of status icons is better served by proper notifications, either through libnotify or GIO.

JFTR, Revolt is already using GNOME notifications through GIO in addition to the status icon.

[clopez]

Not everyone that uses GTK+ happens to use a GNOME desktop. I'm a very happy user of XFCE, and I like the status icon.

[jhasse]

• Have an application setting for "Run in the background" (could be a check box in the app menu)
• When run in the background is true, the app should be included in the autostart list and should continue to run when its window is closed
• Run in the background should default to off, but the app should prompt the user when they first close it, to ask if it should be turned on

One common task I do for my chat application is to turn it off for a moment. With this design I would have to open the app (if there's no notification I need to launch it again somehow), go to settings, uncheck "run in background", close the window. And I would need to make sure I re-enable that setting the next time I start Revolt.

IMHO that is horrible. Right now I just need to right-click on the status icon and select Quit.