Closed cassidyjames closed 1 year ago
This should already be the case: https://github.com/elementary/notifications/blob/master/src/DBus.vala#L123
Ah we really need a demo in Granite or something for notifications. I was testing with notify-send
and it was correctly getting the urgent styling, but not bypassing DND.
notify-send -u critical -i dialog-error "Critical Notification" "This is a demonstration of a critical notification."
Ah this looks like it's due to the difference between notify-send and GLib.Notification like you mentioned at https://github.com/elementary/notifications/pull/11. Not sure if this needs to be addressed then.
Yeah notify send actually doesn't use "urgent" it sends with "high"
Perhaps the user should be able to decide with a toggle..."allow critical notifications"? Right under the DND toggle.
On Tue, 25 Aug 2020, 03:43 Daniel Foré, notifications@github.com wrote:
Yeah notify send actually doesn't use "urgent" it sends with "high"
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/elementary/notifications/issues/86#issuecomment-679393217, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVPTVKGQBYF5MSL4LKDBDSCLQY7ANCNFSM4QJYVJHQ .
I think the power notifications should absolutely always go through.
But there are other potentially important notifications - such as VPN/wifi disconnections, which can interrupt remote work - which might be worth considering.
If you allow some sort of user-defined white-listing, it should be handled in the Switchboard plug and not in the indicator, as this is imho a one-time setup of preferences.
+1 from my end. Beeing able to bypass DnD is beneficial for certain use cases. Battery Power is a good example. I'd also love to bypass DnD in my Time Limit App, because I use the timer to fully focus on work with DnD enabled - but get notified when time is up, so I don't miss other responsibilities. That's something that does not work atm because of DnD swallowing everything.
From the implementation side, can't we just check the app_id
where the Notification is coming from? I think of something like this:
if DnD is on:
if notification.priority is GLib.NotificationPriority.URGENT and
notification.app_id is in system_app_id_list:
send_notification (notification)
else if notification_app_id is in user_bypass_dnd_app_id_list:
send_notification (notification)
system_app_id_list
: is a list of app ids, which are a trusted by the platform (Battery Power Monitor or similar). From these, only URGENT are allowed to bypass DnDuser_bypass_dnd_app_id_list
: is a list of app ids, enabled to bypass DnD regardless of the notification priority in the user's System Settings.It's true that when I use DND on my phone (during night and part of the morning, when I like to think), I block pretty much everything from the outside (messaging clients, emails, even most calls), but I allow notifications from all the apps that do something for me - notes and reminders, travelling app reminders, even calendar (my calendar is rather empty, I didn't get into the habit of filling it, but what gets there usually matters). This way I can plan my morning activity without letting other people mess with my morning activity and loose focus.
So yeah, per-app switches in the notifications plug to white-list apps from the DND rule would be very useful (although the issue described above is less pronounced on the desktop). Of course there is the problem of some apps' notifications showing up as "Other".
Note also there is an issue about it here: https://github.com/elementary/switchboard-plug-notifications/issues/29 - let's go there and upvote it :wink:
Right now it appears critical notifications are swallowed by DND. This has lead to some users accidentally leaving DND on, and then missing critical battery notifications. Do we want critical notifications to bypass DND? If so, are we worried about abuse? If so, how could we curb/discourage abuse? If we don't want critical notifications to bypass DND in general, should we special-case power notifications?
I know this is a bit of a weird format for an issue report, but I think it's something we need to decide and document; afaict it's not documented anywhere.