You Got A Question? Ask    GNOME Community!


A re-designed Notifications API will soon land in Gnome!

This post was made with an older stylesheet


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.


Matthias says:

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

Mathias says:

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!

Goals

  • 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
- Title
- Body
- 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)

Non-Goals

  • 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.

Matthias says:

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 :)

And of course there are also people from companies like Igalia and Collabora which they are doing amazing work for Gnome.


Read More

Matthias Mail
https://mail.gnome.org/archives/gtk-devel-list/2012-November/msg00009.html

Specifications of new API
https://docs.google.com/document/pub?id=1TbzBMft6qs0lFPQ5kUOh6nWfk9M0DgxBwrc8uoHVUgY

Whiteboards Notifications
https://live.gnome.org/GnomeOS/Design/Whiteboards/Notifications

System Settings Notifications
https://live.gnome.org/Design/SystemSettings/Notifications

Gnome Notifications Specs
http://developer.gnome.org/notification-spec/


 
  We can't watch comments unless G+ provides an API or if you send a notification, e.g +World Of Gnome
     Sometimes is better to place your questions on GNOME Community
  • Júlio César Brito

    Great.

  • http://twitter.com/sedremier Timo

    If this gives gnome-shell the stock ability to move the whole chat-notification-thing out of hiding… yey.

    Everything else is working fine as it is, I’d just like to be able to see who sent me how much spam at all times. ;)

  • bulletmark

    Please provide compatibility with Ubuntu/Unity notifications API. Make this new API the only one we need to code for.

  • George Farris

    And for god sakes please consider privacy. We want to know we have a notification but not see it!!!

    • alex285

      There will be a Notification Filtering but other than this, if you want to hide notifications if someone is next to you (if I understand correctly?) you can disable notifications in user menu. You will be able to see them if you open message tray.

  • Pingback: Links 14/11/2012: Linux Mint 14 RC, India’s Educational Android Tablet | Techrights

  • Knighthawk5193

    Make it customizable, the icons that pop-up should be able to be made transparent…..there should be an option for the duration the notification stays active, and we should be able to control it’s size….position…whether it stays in the forefront or show up as a panel/system icon when the entire desktop is covered….etc…!!

  • Pingback: A Screenshot Tour to Gnome Shell 3.7.2+Git | woGue

  • Pingback: A preview of Notifications Filtering for Gnome 3.8 | woGue