3) It can act as a firewall between notifications and the user. In other words, the notification daemon could include user-configurable filters on notifying application, message, urgency level, etc. When a message like "USB device attached" comes along and a user never wants to see that again, they could right-click on that notification window and select an option "Don't show me such notification again" which would open a notification filter configuration window:
Hide future notifications from:
* select: this application / all applications
* select: this message / all messages
* select: urgency level below: (numerical value)
When the notification daemon receives another message that matches an existing filter, it puts that notification in a submenu of the systray icon marked "Hidden Notifications". It does not turn the icon itself red/active. But if the user clicks on the systray icon and selects "Hidden Notifications" they can see the notifications that have been hidden and respond to them or re-enable them if they so desire. After a configurable message lifetime, hidden messages would be automatically removed from the "Hidden Notifications" sub-menu.
To really gild the lily, the notification daemon could allow setting up multiple notification profiles, so that a user could build up different sets of notification filters for different use cases and easily switch among them.
Analogous to iptables firewall, with
ip packet -> notification message
destination -> human user
Speaking of gilding lilies, the analogy could even be extended such that a notification daemon running in one session would *forward* matching notifications to a notification daemon running in another session / user / machine. Not sure that'd really be useful, though, and it gets complex in a hurry.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds