GNOME Bugzilla – Bug 328549
Hide inactive icons
Last modified: 2020-11-07 12:14:24 UTC
This is actually a feature I miss from windows. I like having things on my systray since that saves me desktop and panel space, but that means the systray can get quite bloated too. It would be nice if i could have only active icons show up, like the ones that actually have something to notify me of, or the ones I have most recently clicked on, and have the rest of them hidden. Wouldn't that be great?
This is related to bug 147761. I'm tempted to close this as WONTFIX since applications should really not put icons in the notification area that don't do anything, but I'm keeping the bug open for now... Please file bugs against apps that are abusively using the notification area.
So what's the standard for abusive use of the Notification area?
See http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html :-)
"Displaying an ever-present icon to monitor a continuous background activity". So, Gaim, Rhythmbox and Yarssr woul be considered appropiate? because I have these continuously enabled: one keeps me informed of latest news, other makes me available for communication and the other lets me listen to music without interferring with my work. That makes three, and I don't think they're abusive. Whenever I download anything with epiphany, or I get mail, yet another icon appears and that makes four of them. And... "the utility of the notification area decreases rapidly when more than four icons are displayed at the same time". What I mean is, while you're right by saying that more than three icons on display are BAD for AN, and you're right by saying that applications shouldn't abuse it (I'll take your advice and fill bugs against any case), it's not that extreme to have four icons or even more. Therefore, I have to insist that enabling the ability to hide inactive icons would be a good thing. Actually, what would be the downside of it?
I don't know Yarssr. I consider that the rhythmbox icon is not appropriate, and I'd say the same for gaim when there's no message (but this one is harder). Btw, I'm not saying hiding icons is a bad idea (I didn't close the bug), but it's low priority for me. There are more important bugs in the notification area.
Though I don't agree with you about the appropiateness of the rhythmbox and gaim icons -they're continuously serving me for a purpose but not bugging me while I'm doing other tasks, thus I think it's good that they're there as icons- I have to agree that it's not nearly a top priority issue. It would be sweet to see it some day, bay the NA is fine just as it is. Thanks for your attention Vincent :)
i fully agree with Vincent about rhythmbox icon (there are many bug reports about it but their status are wontfix) HIG has to be respected or GNOME will become an awful mess Considering that report, i vote for WONTFIX
I say Wontfix. The Windows way was just like 90% of things Microsoft does: workarounds instead of solving the core problem. In the GNOME world, we *do* have some kind of authority over application writers (the HIG as a "norm" for user interface design). In the proprietary world, Microsoft is king kong in a jungle. The gorilla cannot control how every insect behaves, so it just fixes the problem by "ignoring" them. +1 on the fact that the pidgin/empathy/rhythmbox notification-icons-that-don't-actually-notify must die.
Any updates on the status of a collapsable notification area? I think this would be useful, at the moment I have pidgin, rhythmbox, screen sharing and low battery in my mouse - That's four icons, and they are all very useful. How would rhythmbox or pidgin run the background without a tray icon? There would be no (intuitive) way of recalling their program instances.
Rhythmbox appears on Window List applet
Nope, not here at least. Either way, I'm trying to say that most tray icons are useful, otherwise I'd disable them. It just would be nice to hide the clutter.
Created attachment 110406 [details] rhythmbox appears on the window list applet > Nope, not here at least. yes, it does. See this screenshot. > Either way, I'm trying to say that most tray icons are useful, otherwise I'd disable them. It just would be nice to hide the clutter. You hide the clutter by not having a clutter in the first place, that means no icon unless you explicitely ask for one on a per-application basis. A "folding" notification area is a band-aid. Not a solution. Fix the damn apps. We have the power to do so.
> How would rhythmbox or pidgin run the background without a tray icon? There would be no (intuitive) way of recalling their program instances. Just to make it clear: as antistress said in comment #10, the intuitive way to recall that they exist is that they show up in the window list. Just like any other normal application. The intuitive way is not a notification area. Just because Windows is a train-wreck of uncontrolled design does not make it intuitive. And yes, I do run pidgin, specto and xchat-gnome without any permanent notification icons. I let those applications stay in my window list, where they should belong. Notifications icons appear only when someone sends me a new chat message, and they disappear after I focus the chat window. It's the way it was meant to be. Rhythmbox sits on my window list (bug #317982), but there's no way for me to get rid of its icon, urgh.
(In reply to comment #12) > yes, it does. See this screenshot. I meant there would be no way to recall it once it was in the background without a tray icon. Making apps display no tray icon results in then unable to function in the background, which _is_ useful for music, IM or similar applications that need to run but don't need your constant attention. Keeping an appliction's tray icon in the task bar is just moving the clutter from one location to another. > A "folding" notification area is a band-aid. Not a solution. Fix the damn apps. > We have the power to do so. You're assuming that if I have enough icons in my tray that it annoys me, then I run broken applications. That's wrong, but not all icons need my attention right now and so it would be nice to hide them. Example, I have a low power notification for my wireless mouse that I don't want to have showing all the time since it starts showing up at 14% battery. Hiding it the icon, switching the battery and wasting 14% of its capacity or having gnome-power-manager appear in the taskbar are possible solutions. I'm sorry, but I don't see any sense in the last two. (In reply to comment #13) > And yes, I do run pidgin, specto and xchat-gnome without any permanent > notification icons. I let those applications stay in my window list, where they > should belong. Notifications icons appear only when someone sends me a new chat > message, and they disappear after I focus the chat window. It's the way it was > meant to be. I understand you may not want to do this as a top-priority thing, but I don't see why completely against this feature. Having it there doesn't mean all users have to use it. If you could point me to the file I would have to modify, I'll be glad to help and make a patch.
> I meant there would be no way to recall it once it was in the background yes there is a way, it's the "window list" which does exactly what it's name implies... > Making apps display no tray icon results in then unable to function in the background pidgin works very well minimized or behind another window, without a tray icon. Rhythmbox would work just as good. > which _is_ useful for music, IM or similar it can be useful. As an option. Users that really need this will be free to decide which applications are more important to them or not. Applications should not make that assumption themselves. > Keeping an appliction's tray icon in the task bar is just moving the clutter from one location to another. What you're missing is that the window list applet (it's not a "task bar") WAS designed specifically for this purpose, that is, list the applications that are running. If they bother you so much, you could send them for another virtual workspace (which were designed to solve this "problem"). You're confusing the utility of the two, the notification area exists to notify, that's it. The rest is either supposed to be managed by the window list or as individual applets. > You're assuming that if I have enough icons in my tray that it annoys me, then I run broken applications. No, I'm assuming that those applications (if your annoyances are warranted) are incorrectly using the notification area for doing something else than transient *notification*. If they are indeed notifications, then that means they are warranted and should not be hidden because it defeats the purpose of them notifying you if you ignore them. If they do not notify you when you want, then it's a bug that you should file on the application so that it matches your tastes. > I have a low power notification for my wireless mouse that I don't want to have showing all the time since it starts showing up at 14% battery that one is slightly debatable, I'd say that most folks would care about their mouse having 14% battery capacity left. It is useful to know that instead of just having the mouse die on you within 2 minutes. For this particular case I'd argue that you should ask gnome-power-manager for a gconf key to be able to set the % at which it starts notifying for the mouse. But I may be completely wrong in my interpretation. I do believe that the Rhythmbox, Pidgin icons do not indicate a process and should not be shown at all times, and having a "hide" features encourages bad design such as those applications. I'd argue that implementing this is a nice way to add potential complexity and bugs, and remove any incentive to app developers to not "assume his application is more important/cool than other applications on the desktop and should nag me all the time".
Stewart Adam : maybe you're right and i'm wrong, therefore why not filling a bug against HIG ? As far as i'm concerned, i find the concept behind the notification area quite simple, and it doesn't seem compatible with the proposal to hide icons in it. The real problem has been described above : some applications make wrong use of notification area, and these applications should be fixed. Sometimes, developers have reasons not to fix it : in nm-applet case, i remember that it has been said that nm-applet is not gnome-specific and that it would be hard to change it into a real applet (instead of sitting in notification area) that would work on several desktop environments. Therefore, if there is no neutral specification for creating an applet that would work as it in multiple environments, maybe that Freedesktop should have a specification that would describe how to make an applet for the desktop ? But it may be another debate
(concerning nm-applet, see http://mail.gnome.org/archives/networkmanager-list/2007-March/msg00057.html )
Okay, I think we're debating about different things - Just to get it straight, I'm trying to point out that I like how certain applications "minimize" to the tray so that they can remain active in the background and be recalled later, without the need to be displayed in the tray. Because of this, it would be nice to have a collapsible notification area. You're trying to say that this isn't what the notification area was designed for, nor are applications supposed to do the whole "minimize to tray" if they conform to the HIG, right?
According to Jean-François Fortin Tam, having certain applications "minimize" to the tray so that they can remain active in the background and be recalled later is not the purpose of the notification area, that's exaclty why the Windows List has been created. Comment #3 give you the link to the "Appropriate Uses for the Notification Area" section in GNOME HIG
Okay, I'll report a bug to the HIG as you mentioned. Sorry about the misunderstanding, I didn't realize that tray icons for applications that run in the background was not HIG compliant. Perhaps we should have separate notification and tray areas/applets?
:) well that's the funny thing, we already do... applets are separate from the notification area (bonus point: the user can position them anywhere!). It's just up to the application devs to make their apps behave as applets to allow users "docking" them into the panel. Otherwise, window list. The only problem is, like antistress mentioned, that applets are not "standard" like notification icons, and as such there would be a need for the way to make an applet to be standardized by Freedesktop.org, or something. That would bring lots of benefits, not just for usability, but for code reusability across desktop environments.
Doesn't an applet need to be added to the panel first, however (IE I won't see the tray icon/applet until I've added it to my panel)?
yeah, I'd guess, unless the distro ships it there by default (for example, ubuntu shipped deskbar applet by default on the panel). At least that's what I think, I'm not sure if there is another way.
We should have a way to auto-add applets and (auto-remove them for when the application closes) in that case, then.
Yes, but you have to fill a different bug for that (i also think that the actual system is hardly discoverable - right cliking on the panel - and that a menu entry will be useful) And before that, you should try to play with some applets to be more familiar with the system PS : i've already filled a bug report on that subject http://bugzilla.gnome.org/show_bug.cgi?id=525523
*** Bug 557929 has been marked as a duplicate of this bug. ***
Off the top of my head: The freedesktop.org notification spec is currently the only desktop-environment-agnostic way of displaying an "applet", which is precisely why so many projects are using it for that purpose. With that in mind: What if the specification had a method to tell the type notification icon available? If the application requested a "notification" type, it would be stating its intention to only have a transient/temporary presence. If instead the application requested an "applet" type icon, it would be a persistent icon that would last as long as the application, desktop session, etc. If the application didn't explicitly request one (for legacy purposes), it could default to an "applet" type. (negotiable?). Also, is there any reason that the "applets" of this kind couldn't be moved around and re-arranged, just like other panel-applets? (On icon creation, create an "applet" which contains it, and lives until the icon is deleted -- then you juts have to save the applet location on the panel somehow). Just brainstorming a little.
Hi Jeremy, one question: how do you show an inactive icon again with your approach? In my view, the inactivity should not depend on the type of application that created the icon, but on how frequently the specific user used it. Moreover, a method to make it reappear when needed should be available, as it happens in Windows/KDE sliding notification area. Just my two cents. Alberto
Thinking about it more, I think in my perfect world, they would never be hidden, unless the application requested it. If it's just a plain old ordinary notification icon with no other information, we can't make assumptions about whether it's appropriate to hide it or not. However, since it would fall into the "applet" category, the user could right-click on it, and perhaps remove it that way, or move it to a drawer somewhere. (I don't suppose there's any standard for interacting with these icons?) Now, if the application describes itself as transient, it could hide itself, or the desktop environment could remove it.
You can make assumptions based on how often that icon is clicked or used for example. And anyway, the idea is to have a less crowded notification area, without acually removing the icons in case the user needs them. The behaviour should no only depend on the nature of the application. For example, in my use case, the blootooth icon can be hidden for a long time, same for NetworkManager, video settings, battery charge when plugged and some others. Of course this assumes the notification area can actually become a sort of horizontal drawer, and can react to events triggered from the applications which place an icon in it.
I suppose in principle if you had eye tracking, you could perhaps tell if the icon is something being used for status monitoring -- but even then it's probably something for your peripheral vision. I don't think there's any practical way to automatically infer the type of application -- the application must provide it.
Considering the current situation has not alternatives to a overcrowded notification area, which might extend to more tha 1/3 of the whole panel, becoming a problem for those that use only one panel in their desktop, I would start keeping it simple. ;-) If you need some icon to be always shown, you can simply override the auto-hide by putting it in a list, exactly as it happens on Windows and I think also in KDE.
Repeating myself: Windows' (and KDE's, if they really do that) notification area are a *fucking usability disaster*. I do not want the ability for the notification area to play slinky with the icons (I guess my position on was clear from my long comments above :). It would make the situation worse. The solution is to fix the attention-craving apps, not put a "band-aid". Otherwise you're giving even less incentive for app makers to follow the design guidelines. (P.s.: I don't mean to offend, I have nothing personal against you or anyone else. Just repeating my thoughts in a clear/concise way. More detailed arguments in the previous comments.)
Concerning nm-applet , How about adding an option for the icon, similar to gpm: [*] Always display an icon [ ] Never display an icon for the wired users the constant presence of the nm icon may not be needed , the icon could be displayed only when disconnected or some other error .
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.