I have some scripts that make use of notify-send to show a message to user when work occurs. In Gnome 2 (Fedora 14), this briefly displayed message on screen and then was gone: notify-send subject message In Gnome 3, this is still true but in addition it adds an icon onto notification panel (what ever its called when you put cursor in lower right corner). These build up over time and are a pain to clear out. You have to click on each icon and then click on message that pops up to remove icon from panel. Is this a bug or feature? Shouldn't notify-send be able to send-and-forget messages that require no further user interaction?
This is really a gnome-shell issue
OK, I started here because I heard there were likely lots of distro specific patches while preparing for release. Should I submit a report on gnome bugzilla?
Give this a crack: notify-send --hint=int:transient:1 Test
Yep, I verified that the --hint option in comment #3 does not keep the notification around. I guess that means this bug can be closed.
That option doesn't work for me. The notification is still sticking around.
Never mind. Its begun to work. It remained on the first try though.
It would be nice to "remove icon from panel" by clicking it with the middle mouse button, FWIW.
My use-case: I am running irssi on a remote machine and have tweaked "notify.pl" [1] plugin to run notify-send via SSH connection back to my station. And it literally clutters up notification panel (as the subject reads) for me. If I make the notifications transient, I can miss some notifications I'd rather not. That possibility I mentioned in comment 7 would be a little help for me in the current state (lets mark this 0a/). Perhaps better for me would be to set a notification timeout (0b/). Is there anything like this already? But inspired by how ABRT groups its events under a single icon [*], I have a following proposal: 1/ Let's make standard (non-transient) notifications from notify-send (or generally via libnotify?) be grouped in the notification panel (as in ABRT case) according to the program (it's path, PID?) that sent the notification and/or add a possibility to tag the notification so the notifications with the same non-empty tag can be grouped in the same manner. The other proposal concerns general usability of notification panel once it got cluttered up: 2/ Let's make notification-panel *at least* mouse-scrollable. Even better would be to add a behavior that the panel scrolls automatically once it is displayed + cursor is near its right/left edge. Otherwise, you have to remove new notifications to reach the old ones (on the right). Any thoughts on the proposals or suggestions for my use case (beside using another notification framework)? [1] http://irssi-libnotify.googlecode.com/svn/trunk/notify.pl [*] will attach a screenshot for demonstration in the next comment
Created attachment 529345 [details] Demonstration of how ABRT is grouping its messages. Notice also that it is indicating the number of grouped messages as the notification icon overlay.
On Fedora 16, since installing upgrades, I have this issue with Transmission. Before this recent upgrade, Transmission notifications would queue up in the tray icon for Transmission itself, with a notification count hint as a bubble on the tray icon. Since the upgrade, I get a new Transmission icon in the tray for each notification, labeled "notify-send".
Since I can't change the caller of notify-send, I resorted to creating a bash wrapper named notify-send that calls my-notify-send (the binary) with the args in comment #3. It is highly annoying to have these bubbles stack up and no way to clear them all.
Created attachment 531131 [details] Showing annoyance of notify-send
Re comment 8: My bad, 0b/ (notification timeout) must be already present for a long time: --- $ notify-send --help [...] Application Options: [...] -t, --expire-time=TIME Specifies the timeout in milliseconds at which to expire the notification. [...] --- I think I had knew about that but forgot/not rechecked it by the time of writing the comment. However, 0a/, 1/ and especially 2/ remain opened and IMHO are worth considering.
The concrete issue was found fixed in Comment #4. I don't think there is anything concrete left to do here. Discussion of the tradeoffs of the gnome-shell message tray design should really happen upstream with the GNOME designers.
notify-send --hint=int:transient:1 Test I tested it. As soon as the notification disappears, it is stored. However I am using Cinnamon, and not Gnome3. It shouldn't make a difference since I am calling notify-send with --hint=int:transient:1 http://expectusafterlun.ch/screenshot.png