notifications in gtk

[Matthias Clasen <matthias clasen gmail com>]

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, lets have
a look at these designs (for GNOME) before getting into the details:

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

Two important requirements for a notification api coming out of these are:

- Have a clear connection between notifications and the app that sent
them - 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 (like
evolution-alarm-notify), or do their notification 'by proxy' (e.g
software update notifications coming from gnome-settings-daemon)


The existing solutions (GtkStatusIcon, libnotify) have limitations
that prevent us from fully implementing these designs:

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.

>From a very high level, the api that we propose can be summarized as:

gtk_notification_new()
gtk_application_add_notification()

For full details, see the spec:
https://docs.google.com/document/pub?id=1TbzBMft6qs0lFPQ5kUOh6nWfk9M0DgxBwrc8uoHVUgY

You may ask why we are proposing a C api, and not a D-Bus interface -
the answer is that most applications will be using the C api, so we
should make sure we get it
right, rather than treat it as an afterthought that is derived from
the D-Bus api. Also, keeping the D-Bus interface (semi-)private will
allow us to evolve it - much like we're currently treating the various
GApplication D-Bus apis. The D-Bus api will still be available for
edge cases, like system notifications that are not coming from an
application. But the C api is intentionally very application-centric.

Note that several details in the proposal are still very much up for
discussion, such as requiring a D-Bus service file for activation.
Feedback is really appreciated!


Portability considerations

- Most of the GtkNotification api can probably be implemented against
org.freedesktop.Notifications (except the fire-and-forget aspects),
and this is what I think we should start out with

- The api that we are presenting here is fairly similar to OS X'
NSNotification api, and should be easily implementable on top of it

- After looking for notification apis on windows, we are confident
that this api proposal is confident with the win8 notification
guidelines and api ('toast'...). It will not be a very good fit for
traditional icon+balloon messages.


Roadmap considerations

- 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


Let us know what you think about this.


Matthias

PS: 'we' in this mail is Cosimo, Jon and me - though Cosimo and Jon
did all the work, really