Some applications need to inform the user of events in the workbench that may require attention, whether or not the workbench is visible. An increasingly standard way of doing this is to use a desktop notification popup, often appearing for a fixed amount of time in the bottom-right hand of the window.
Ideally this mechanism would use the native operating system's mechanism for notifications. However, we do not yet have standard APIs for notifications on Windows, Linux or Mac (while Growl is a popular notification system for the Mac, it is not a part of the OS). Eclipse projects such as Mylyn make heavy use notifications, as do Eclipse-based products such as Jazz and Tasktop. To avoid the usability problems of having various plug-ins' notifications using different mechanisms, the Eclipse Platform should provide a common notification API.
The Mylyn Commons API component currently provides the desktop notification popup used by Mylyn, implemented via bug 177974. The notification popup and notification manager are currently provisional. Popups fade into view, are sticky when the mouse is over them, and fade out if the mouse has exited or the set amount of time has elapsed. It currently supports:
- Different types of notification events (e.g., overdue tasks, new comments on bugs).
- A default action for each event, invoked by clicking the events' hyperlink or icon (e.g., opening a task editor).
- Actions/commands associated with the event (e.g., click the incoming arrow to mark the task as read).
Jazz is very interested in Platform API in the area of notifications. Jazz already provides a very generic and extensible framework for notifications and events. The framework defines the following terms in order to describe its functionality
A Notifier is a mechanism to inform the user about a certain Event. For instance, the alert-notifier opens a small alert above the tray-area to inform the user about an Event as shown in the following screenshot.
You can see a short flash video showing incoming alerts - including stacking - in Jazz in action from Media:Alert_camtasia.zip.
The Event provides a generic description that is used by the Notifier to present the Event in the UI. E.g. the Event provides a description, severity and priority. Some examples for Events in Jazz:
- a build has failed
- a defect was updated
- a team member wants to chat
Lastly, a Trigger defines the enabled-state of a certain Notifier for a certain Event. E.g., a Trigger may define to show the alert-notifier for high-severity work item change-events. Thus, a Trigger is the combination of a Notifier and a family of Events under a certain condition.
In the attached screenshot of the "Notifications" preferences page (see below) you will see the three terms in action. On the left hand side is the list of contributed event categories and types (Events). Top right you can see the event Triggers. The selected one will highlight high priority events in red. As you can see, this is totally independent from showing an alert. The idea is that a notification can have any UI (this is extensible, e.g. Growl is one way to show a notification). Finally in the lower right corner, a list of contributed Notifier is showing.
Sending events is easy. A static method Notification.send(String eventTypeId, NotificationInfo info) is provided to issue a notification for the given event type. The NotificationInfo is made up of:
- detail (any metadata being transported)
- runnable (executed on click)
A more in-depth explanation of the Jazz notification framework is available from the Jazz wiki. Find the topic "Foundation Notification Tutorial" attached as archive from Media:FoundationNotifierTutorial.zip
Summing up the requirements for Jazz:
- presentation independent API to issue events
- extensible presentations for events (Alert, Growl,...)
- a modern, customizable alert widget
- title area with icon, optional menu and close button
- capable of showing multiple events stacked including navigational controls
- customizable content area
- configurable animation (fading, movement)
- OS colors for a decent integration
Platform should provide:
- A common notification service that dispatches notifications to a presentation layer. We need to figure out if there is overlap with the status service.
- A generic notification popup suitable for us by RCP and SDK-based applications.
Extensions can provide:
- Integration with OS-specific notification mechansims (e.g., Growl).
- New notification popup UIs with additional features (e.g., richer interaction).
- Adapt to OS color.
- Vista notification guidelines: http://msdn.microsoft.com/en-us/library/aa511497.aspx
- Mac notifications via Growl: http://growl.info
- Linux notifications project: http://www.galago-project.org/specs/notification