Many application (ie Skype, Lifearea, Dropbox etc) are still using Legacy Notification Icons in Gnome Shell, and apart that the ugly result, it is also unpractical in use both for desktop and touchscreens.
While there is no plan to map the legacy GtkStatusIcon model, the new notification API promises to make everyone’s life easier and it will bring some new exciting features!
Matthias Clasen points the issues with the current implementation and marks the need for a new API, and Cosimo Cecchi -who’s working at it- talks about the benefits of the new API.Of course the new API will bring many more goodies and it will implement all these goals that were set from beginning of Gnome3.
It has been clear for a while that GTK+ should provide an api to support notifications, so that applications don’t have to a separate library (libnotify) for such a minor detail. Since our apis should serve the application designs that are implemented with it
Requirements for a Notification API
- Have a clear connection between notifications and the app that sentthem – this is necessary to do notification filtering based on application, as can be seen in the system settings design
- Allow future delivery of notifications and allow notification actions to activate apps – without this, apps that have to do ‘scheduled’ notifications have to grow a daemon mode (likeevolution-alarm-notify), or do their notification ‘by proxy’ (e.g software update notifications coming from gnome-settings-daemon)
Problems with GtkStatusIcon
- It is really centered around the idea that apps just export a small bit of their UI into the ‘panel’
- It assumes that all desktops want to offer a permanent place (“system tray”) for applications to present a clickable icon with a context menu
- It requires the application to be running as long as its icon is present, essentially forcing a daemon mode onto applications (eg evolution-alarm-notify)
- The X implementation uses XEmbed and can’t really be made to work nicely in a composited environment
- The win32 implementation is also problematic
Problems with libnotify
- No clear connection between notifications and the originating application
- Also requires the application to be running as long as it wants to present notifications
- Problematic life-cycle with the notification objects (partically historically: ref-counting for NotifyNotification changed at some point, and to this day many applications are leaking their notification objects)
- Separate library, no OS X or win32 support
A new API
GtkApplication is a very natural candidate for providing a notification api, since notifications should really be tied to applications. We get application ids and other metadata such as bus names, icons, translated descriptive names, etc, for free.
We also get to reuse GAction for actions. And GAction already has a very flexible state mechanism (based on GVariant), which will allow us to implement future delivery and fire-and-forget.
Cossimo Cecchi has recently started working on a new API according with these specifications. Cosimo describes some of the Benefits to Gnome.
It would be very difficult to think about a way to map the legacy GtkStatusIcon model to the new notification API – Matthias outlines several issues with GtkStatusIcon in his mail. So at the moment we don’t plan to automatically translate status icons into notifications – but the Shell will still support displaying both legacy status icons pretty much as it does now and notifications triggered using the previous libnotify protocol. Third party applications will need to be modified in order to use the new notification system to its full extent.
Benefits to Gnome
- applications will be able to use a modern and well-defined API in the base platform to display notifications, and integrate with the rest of the system, without any additional libraries
- applications will be able to add, list or revoke notifications previously scheduled, even if the application closed or crashed in the meanwhile (no more information lost because the app backing a notification crashed while you were away)
- applications will be able to schedule notifications without stay running in the background all the time, and be resumed when the notification date expires (think e.g. about Clocks scheduling an alarm notification for the next day and being automatically executed when it reaches the right time)
- it will be possible for a notification to spawn its backing application if it’s not running
- applications will be able to associate a set of actions with arbitrary states to a notification, and read back such information when the notification is activated, independently of their running state
- notifications for long running services and remote push notifications will be possible to implement
- users will be able to configure notification settings per-application in a System Settings panel
Scheduled Notifications -both for local and Cloud Applications-, configurable settings for each App, an easier API for developers ..and much more!
- Separate content and presentation of notifications
- Do not require a persistent connection to present notifications (robust against application crashing and closing)
- Allow background applications to inform users
- Allow non-running applications to inform users
- Allow remote services to inform users on behalf of a local application
- Allow service subsystems to alert users on behalf of a local application
- Allow an application launched or brought to the foreground to direct the user to the relevant information
- Allow applications to present contextual actions with the notification
- Support user modification of notification policy (putting the user in control of what may interrupt them)
- Allow applications to cancel or recall (one or all) notifications
- Support for the following information for all notifications:
- Application icon
- Application name
- Support for the following option information:
- Supplementary image data (album artwork)
- Custom alert sound
- Allow the user to:
- prevent display of an application’s notifications
- specify whether an application’s notifications may appear on a locked screen
- specify if an application should present banner or modal type notifications
- Support for future event delivery (for clock and calendar alarms)
- Support for positioning notifications
- Support for notification display timeouts
- Support for notification categories
- Support for application specified urgency levels
- Support client/server capabilities negotiation
When will this come in Gnome?
This work has been recently started and even if the new API will arrive for Gnome 3.8, the complete feature list will arrive later, as it requires the new Gnome Control Center , which Gnome UX also work currently, but is far from completed.
We’re not sure if it is realistic to get far enough with this in time for 3.8; I could see a phased approach, where we only introduce the GtkNotification api and a fallback implementation (ie talking to org.freedesktop.Notifications) in 3.8, and get a full implementation with a new server-side D-Bus interface in 3.10
GtkStatusIcon should be deprecated when the new API has landed
In general there is a lot of infrastructure work happening in Gnome and I think that Gnome future is secured and exciting. Apart from developers that work directly in Gnome like Matthias, Jasper, Cosimo and others, there are some heavy names, Emanuelle Bassi (Clutter), Kristian Høgsberg (Wayland), Lennart Poettering (systemd) just to mention few, that every Desktop Team would be happy to had them :)
Specifications of new API
System Settings Notifications
Gnome Notifications Specs