After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 328549 - Hide inactive icons
Hide inactive icons
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: notification area
2.12.x
Other All
: Normal enhancement
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 557929 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-25 09:45 UTC by David Prieto
Modified: 2020-11-07 12:14 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
rhythmbox appears on the window list applet (38.71 KB, image/png)
2008-05-05 14:06 UTC, Jean-François Fortin Tam
Details

Description David Prieto 2006-01-25 09:45:49 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?
Comment 1 Vincent Untz 2006-01-25 17:49:31 UTC
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.
Comment 2 David Prieto 2006-01-25 18:07:46 UTC
So what's the standard for abusive use of the Notification area?
Comment 4 David Prieto 2006-01-25 20:41:25 UTC
"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?
Comment 5 Vincent Untz 2006-01-26 10:07:31 UTC
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.
Comment 6 David Prieto 2006-01-26 13:04:51 UTC
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 :)
Comment 7 antistress 2008-04-24 20:52:31 UTC
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
Comment 8 Jean-François Fortin Tam 2008-04-24 21:45:29 UTC
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.
Comment 9 Stewart Adam 2008-05-04 15:52:44 UTC
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.
Comment 10 antistress 2008-05-04 18:36:40 UTC
Rhythmbox appears on Window List applet
Comment 11 Stewart Adam 2008-05-05 01:43:05 UTC
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.
Comment 12 Jean-François Fortin Tam 2008-05-05 14:06:40 UTC
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.
Comment 13 Jean-François Fortin Tam 2008-05-05 14:16:24 UTC
> 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.
Comment 14 Stewart Adam 2008-05-05 20:56:30 UTC
(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.
Comment 15 Jean-François Fortin Tam 2008-05-05 22:40:28 UTC
> 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".
Comment 16 antistress 2008-05-05 23:05:14 UTC
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

Comment 17 antistress 2008-05-05 23:09:22 UTC
(concerning nm-applet, see http://mail.gnome.org/archives/networkmanager-list/2007-March/msg00057.html )
Comment 18 Stewart Adam 2008-05-05 23:18:51 UTC
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?
Comment 19 antistress 2008-05-05 23:45:04 UTC
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
Comment 20 Stewart Adam 2008-05-06 00:19:58 UTC
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?
Comment 21 Jean-François Fortin Tam 2008-05-06 14:52:07 UTC
:) 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.
Comment 22 Stewart Adam 2008-05-06 20:55:27 UTC
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)?
Comment 23 Jean-François Fortin Tam 2008-05-07 01:33:55 UTC
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.
Comment 24 Stewart Adam 2008-05-07 03:22:55 UTC
We should have a way to auto-add applets and (auto-remove them for when the application closes) in that case, then.
Comment 25 antistress 2008-05-07 14:25:08 UTC
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
Comment 26 Philip Withnall 2008-11-14 19:48:59 UTC
*** Bug 557929 has been marked as a duplicate of this bug. ***
Comment 27 Jeremy Nickurak 2009-06-15 20:26:21 UTC
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.
Comment 28 Alberto 2009-06-15 21:37:27 UTC
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
Comment 29 Jeremy Nickurak 2009-06-15 22:23:07 UTC
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.
Comment 30 Alberto 2009-06-15 23:33:53 UTC
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.
Comment 31 Jeremy Nickurak 2009-06-15 23:37:51 UTC
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.
Comment 32 Alberto 2009-06-16 00:26:02 UTC
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.
Comment 33 Jean-François Fortin Tam 2009-06-17 01:32:09 UTC
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.)
Comment 34 Vish 2009-08-31 17:13:20 UTC
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 .
Comment 35 André Klapper 2020-11-07 12:14:24 UTC
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.