GNOME Bugzilla – Bug 672636
critical, transient messages are not treated as transient
Last modified: 2012-06-01 17:51:59 UTC
The Ubuntu-patched network manager sends a "network disconnected - you are now offline" message with urgency critical and transient hint. Gnome-shell ignores the transient flag on critical messages, so the message lingers until clicked upon. This is somewhat annoying. The relevant bug on launchpad is [1]. It is not difficult to make transient messages actually behave transiently. I've attached a patch that does this. It doesn't change the ordering of messages (so critical messages will still appear before all others) but for the rest, a transient, critical message will behave as a normal message. I'd love to hear your opinion. [1] https://bugs.launchpad.net/bugs/883443
Created attachment 210355 [details] [review] patch to make transient notifications expire.
Ahem, actually, why does Ubuntu patch nm-applet that way? (Or actually, why don't they patch it to silent "network disconnected" messages, which are annoying and mostly useless).
Network disconnected message serve a purpose: it's useful to let the user know that they are completely offline (which is the only case affected by this issue, as the other disconnections that don't result in an offline state aren't CRITICAL) and shouldn't expect "online" operations to work. Just the disconnected icon isn't quite sufficient for this. All the notifications created by nm-applet are set the 'transient' hint. Should all transient notifications actually react as being transient and eventually disappear, or has there been a conscious decision to override this in the case of NOTIFY_URGENCY_CRITICAL notifications?
(In reply to comment #3) > All the notifications created by nm-applet are set the 'transient' hint. Should > all transient notifications actually react as being transient and eventually > disappear, or has there been a conscious decision to override this in the case > of NOTIFY_URGENCY_CRITICAL notifications? To be honest, I don't think notifications that are both critical and transient make much sense - the former implies that the information is so important that the user must not miss it (which is why we require users to explicitly acknowledge critical notifications), while the latter are useful when emitted, but perfectly fine for users to miss (which is why they are not kept around in the summary tray to get back to them later). Note that from a purely technical point of view, transient-critical notifications already behave like any other critical or transient notification - they are kept in banner mode until acknowledged (critical) and not shown in the summary tray after hiding the banner (transient). Even if both hints changed the duration notifications are shown (which only "critical" does), it would seem wrong to give the "this-is-not-that-important" hint priority over the "this-is-very-important-dont-miss" hint. So I do think that Ubuntu's patch is wrong - they don't mark "disconnect" notifications as critical because they consider the information important enough to not be missed by users, but for the (implementation-dependent) side effect of moving critical notifications to the top of the queue ("show as soon as possible"). (On a side note: it is clearly wrong to keep the notification around after the network became available again, so the notification should be explicitly closed in that case)
Fair enough. I'll see if this is sufficient rationale with the Ubuntu design team to drop the Ubuntu patch for this (or at least revert to priority normal or something). I agree that there's definitely no point in keeping the notification around after a reconnection, at least, but the implementation in light of how the rest is done isn't immediately obvious to me.
A side note: if you revert gnome-shell/f65826b3ba2cf03a859819e6706046fff376c65c you get notifications from the shell itself. Those are already dismissed when the connection comes back, have the right priority and allow you to kill nm-applet from the shell session once you target 3.4.
Thanks, that's very helpful.
There seems to be agreement that this is not a bug (at least upstream), so let's close this.