Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Development (http://www.linux-archive.org/ubuntu-development/)
-   -   Unified notification daemon / systray icon? (http://www.linux-archive.org/ubuntu-development/257727-unified-notification-daemon-systray-icon.html)

Frank Myhr 03-05-2009 04:36 PM

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

Andrew Barbaccia 03-05-2009 08:42 PM

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 02:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.