Unified notification daemon / systray icon?
Hi,
I recently became aware of the ongoing discussion about notification bubbles through an article at lwn.net: http://lwn.net/SubscriberLink/321884/5d9494a1a2842c24/ It got me thinking about a possible way of handling notifications that could please a wide variety of users. I posted the idea at the above lwn link and got some feedback there, but thought I'd summarize it here as well. Maybe parts of it could be useful as the Ubuntu team works on the new notification interface. -Frank The basic idea is to extend the concept of adept-notifier / update-notifier-kde (or gnome equivalent) to apply to all notification bubbles. Applications would send all user notifications to a single unified notification daemon (UND) that would have a single unified notification icon (UNI) in the system tray. That UNI would normally be grey, easy for the user to ignore. When the UND receives a user notification it turns the UNI red (or another user-configurable color / shape). Depending on the urgency level of the notification and user configuration (see below), the UND may or may not display a notification bubble above the UNI. In most cases no bubble would be displayed, and the user can choose to simply ignore the red UNI. If the user chooses to see the notification, they click on (or hover over, depending on user configuration) the UNI, which then displays a menu listing the applications that have sent notifications. The user selects which of those apps (one choice could be "all") and all of that app's notifications are displayed. As the user responds to each notification, it is removed from the UNI. When there are no notifications left, the UNI turns back gray. Routing all notifications through a single UND / single UNI has the following benefits: 1) All notifications appear in the same place, no need for the user to go hunting for them. 2) Notifications are easy for the user to ignore (or not) depending on how they're using the system at the moment. 3) The UND may save memory, as compared with multiple notification daemons. 4) The user can configure their system-wide notification preferences in a single place. Expanding on benefit (4): The UND can act as a configurable firewall between notifying apps and the user. Taking an example from the lwn article: the user plugs in a usb device. The event/usb subsystem sends a notification "Device connected". There are 3 user reactions to this notification: i) Never interrupt me with this notification! I _know_ there's a usb device connected, I'm the one who just connected it! ii) Thank you for confirming that the system recognizes that I just plugged in a usb device. Always show me this confirmation. iii) Sometimes I want to see this notification (trying out a new device), and other times not (connecting a usb device in the middle of a presentation). The UND can satisfy all 3 of these cases: i) If the user doesn't want to see future such messages, they right-click on the notification bubble 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 UND receives another message that matches an existing filter, it puts that notification in a submenu of the UNI marked "Hidden Notifications", and does not turn the UNI red/active. But if the user clicks on the UNI 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 notifications would be automatically removed from the "Hidden Notifications" sub-menu. ii) No action required. iii) The UND 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. Another lwn reader pointed out that there are some notifications such as battery charge and wireless link that the user wants to see at a glance, without having to click the UNI and navigate its menus. If the user wants to see a dedicated notification icon for a particular app, they could right-click on the notification bubble and select "add icon to systray". That would bring up a configuration window with: - name of app sending the notification - icon to be added to systray, with button to select a different one - radio buttons: x pop up message windows above systray icon x click systray icon to see messages The UND would then send all notifications from that app to the dedicated systray icon rather than the UNI. The user could right-click the dedicated notification icon and select the option "move to universal notification icon" in order to undo the steps above. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel |
Unified notification daemon / systray icon?
On Thu, Mar 5, 2009 at 12:36 PM, Frank Myhr <fmyhr@fhmtech.com> wrote:
Hi, I recently became aware of the ongoing discussion about notification bubbles through an article at lwn.net: http://lwn.net/SubscriberLink/321884/5d9494a1a2842c24/ It got me thinking about a possible way of handling notifications that could please a wide variety of users. I posted the idea at the above lwn link and got some feedback there, but thought I'd summarize it here as well. Maybe parts of it could be useful as the Ubuntu team works on the new notification interface. -Frank [snip]* Routing all notifications through a single UND / single UNI has the following benefits: 1) All notifications appear in the same place, no need for the user to go hunting for them. 2) Notifications are easy for the user to ignore (or not) depending on how they're using the system at the moment. 3) The UND may save memory, as compared with multiple notification daemons. 4) The user can configure their system-wide notification preferences in a single place. [snip]* iii) The UND 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. Hello all, this is my first post on this list but I've been following the*discussions for a bit.* I'm going to agree with Frank's approach and offer a suggestion of my own.* We currently have an applet that sits in the tray displaying the user's state (I'm not sure of the name but it has the logout / shutdown options as well). It's integrated with pidgin so that a change in state will reflect a change in online status and vice versa. If we were to implement profiles for notifications, changing the state in this applet should also change the notification profile as well. (Eg. If you pick "Busy" then a no notification profile should be selected) I understand that implementation is the smaller battle compared to determining what profiles, which notifications, and how much verbosity is appropriate but I thought I'd include my 2 cents and introduce myself. -- Andrew Barbaccia -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel |
| All times are GMT. The time now is 07:35 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.