Re: [Ayatana] Merging libindicate into libnotify

[Dylan McCall <dylanmccall@xxxxxxxxx>]

> The existence of libindicate is something that has always
> bothered me. The not-necessarily-immediate-response case
> is a common scenario required by a significative number of
> applications, and requiring those applications to support
> an extra library (and thus extra patching for working in
> Ubuntu) is unpleasant.
>
> Shouldn't this case be covered by the Notification Spec and
> each desktop offer a standard single mechanism for handling
> them, independently of the app? Shouldn't the Messaging Menu
> drop the "messaging app" requirement and become the standard
> Ubuntu mechanism for handling these kind of notifications?

This is something that _is_ covered by a particular subset of the
notification specification; it's just that it isn't guaranteed. Gnome
Shell is doing what you want here: they went ahead and defined
persistent notifications, which their message tray is optimised for.
Unfortunately, it's all wrapped into the same notification
specification for some reason. The platform as a whole now has an
impressively convoluted setup for notifications. It's almost as if we
don't want people using these. Here's what an application must do, as
I understand it:

* First, I will ask the notification server for its capabilities. Does
it support persistence?
* Yes? Great, I'll show a resident notification.
* No? Okay, just give it a long life and a few actions, I guess.
* I can't do actions? Okay, change the message to reflect that, maybe
tell the user where to find me.
* Wait, do I even know what this notification server is doing? Ugh,
it's probably notify-osd. I guess I'll assume it's a transient
notification.
* Am I reading the right version of the notification spec?
* Well, now that I've gone this far, it can't hurt to add libindicate. Right?
* Do I actually belong in the messaging menu? Don't care: I want a
resident notification, and my developers don't want to maintain any
more strings!
* The end.

Android does this well:
http://developer.android.com/guide/topics/ui/notifiers/index.html
There is no overlap. Each type of notification is optimised for one
task. You choose, from the onset, if you want a Toast notification, a
Status Bar notification, or a dialog notification. Each one does
exactly what it says on the tin and it does it well. An application
doesn't waste resources trying to figure out how to present a
notification at runtime and the system knows exactly how each type of
notification is meant to be displayed.

Perhaps there is room for consolidating Ubuntu's great work on
transient notifications and Gnome's great work on persistent
notifications by managing these as separate systems with their own
specifications. Because, as the messaging menu pretty clearly reminds
us, they are.


Dylan