GNOME Bugzilla – Bug 779974
Turning notification banners off doesnt turn off all notification banners
Last modified: 2017-10-26 17:52:53 UTC
Created attachment 347820 [details] zotero notification banner I have notification banners turned off inside my notification settings. But I still see this banner sometimes: Zotero "Software Update" is ready I think this banner is triggered because this application searches for software updates in the background and spawns a dialog on a different workspace or while unfocused without any action done on my part. Anyway, doesnt turning notification banners off that i shouldnt see any banners at all? I would assume even banners like these should just go straight to the message tray.
Right, this is a banner from gnome-shell itself, after the app was prevented from stealing focus. This is an easy fix, we just have to figure out what behavior we want: - follow the "master" notification settings, that is the "Notification Popups" switch in Settings - follow the per-app settings for the corresonding app
(In reply to Bastian Ilsø from comment #0) ... > I have notification banners turned off inside my notification settings. But > I still see this banner sometimes: > > Zotero > "Software Update" is ready Just because someone has notifications turned off doesn't necessarily mean that they don't want any notifications to ever be displayed. Critical power warnings come to mind. In your case, do you definitely not want to see that notification? Can you explain why not?
(In reply to Allan Day from comment #2) > Just because someone has notifications turned off doesn't necessarily mean > that they don't want any notifications to ever be displayed. Critical power > warnings come to mind. This makes sense, but a quick peek at the code suggests that right now we are in fact applying the policy to critical notifications like power warnings :-) Maybe the "master" setting shouldn't be a simple switch, but a slider from "none" over "only critical" to "all"? I'm a bit wary of exempting all critical notifications from any policy, as it provides some incentive to apps to abuse the hint for getting around restrictions ... In any case it's a different issue than the one raised in the bug: the notifications in question aren't critical at all, they just get a free pass for being emitted by gnome-shell itself rather than some other component.
(In reply to Florian Müllner from comment #3) ... > Maybe the "master" setting shouldn't be a simple switch, but a slider from > "none" over "only critical" to "all"? I'm a bit wary of exempting all > critical notifications from any policy, as it provides some incentive to > apps to abuse the hint for getting around restrictions ... ... I'm not sure how you avoid that. There are some notifications that you just want to see, no matter the situation - an alarm, an incoming call, the fact that you're almost out of power...
Created attachment 347869 [details] [review] messageTray: Ignore showBanners policy for critical notifications The critical hint is meant to be used for notifications that must not be missed - running out of battery being the prime example - so it makes sense to ignore the policy in that case and make sure to always show them to the user. This is consistent with blocking normal notifications while showing a fullscreen window, but letting critical ones through. (In reply to Allan Day from comment #4) > There are some notifications that you just want to see, no matter > the situation Poor Bastian, asking for *less* notifications, and we are showing him *more* ...
Review of attachment 347869 [details] [review]: Sure. But what about applying a policy to the WindowAttentionSource? It seems like we could use a NotificationApplicationPolicy there.
(In reply to Rui Matos from comment #6) > But what about applying a policy to the WindowAttentionSource? It seems like > we could use a NotificationApplicationPolicy there. Yeah, or a NotificationGenericPolicy, see comment #1. I'm unsure which is the better option, as those notifications don't really come from the app. But I don't think they are so indispensable that they have to be shown at all cost, regardless of any user settings.
Comment on attachment 347869 [details] [review] messageTray: Ignore showBanners policy for critical notifications Attachment 347869 [details] pushed as 60a2794 - messageTray: Ignore showBanners policy for critical notifications
Created attachment 362358 [details] [review] windowAttentionHandler: Follow app policy for attention notifications While window attention notifications are created by the shell itself rather than applications (most likely as a result of focus stealing prevention), users still commonly link them to the application for which they are shown. It makes therefore sense to follow the appropriate policy set by the user rather than showing them unconditionally.
Review of attachment 362358 [details] [review]: otherwise makes sense. didn't test ::: js/ui/windowAttentionHandler.js @@ +82,3 @@ + _createPoliy: function() { + if (this._app && this._app.get_app_info()) { + let id = this.app.get_id().replace(/\.desktop$/,''); this.app doesn't seem to exist in either this class or the parent. Do you mean this._app.get_app_info().get_id() ?
Attachment 362358 [details] pushed as eecbd4d - windowAttentionHandler: Follow app policy for attention notifications (In reply to Rui Matos from comment #10) > this.app doesn't seem to exist in either this class or the parent. Do you > mean this._app.get_app_info().get_id() ? Yeah, I meant this._app.get_id() ...
Review of attachment 362358 [details] [review]: ::: js/ui/windowAttentionHandler.js @@ +80,3 @@ }, + _createPoliy: function() { There is a typo. It should be `_createPolicy`.