Re: [Ayatana] Merging libindicate into libnotify

[Conscious User <conscioususer@xxxxxxx>]

Le jeudi 31 mars 2011 à 12:35 -0700, Dylan McCall a écrit :
> 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.

In my opinion, separating the systems is not necessary, and wrapping
all cases in the same specification is not a bad thing.

The main problem is, as you pointed out, this "GetCapabilities" mess.
The applications should not *care* whether the server supports
persistence or not: it should just say that the notification is
supposed to persist. Whether the server will do this competently,
is not the applications' problem.

But save for this "GetCapabilities" issue, the specification is fine.
The serves are broken. Gnome3 is too optimized for persistent
notifications, while Ubuntu is too optimized for transient
notifications. Ideally, someone developing an application for Ubuntu
should not worry about using something like libindicate: he should use
only libnotify, and NotifyOSD would be responsible for throwing
persistent notifications to something like the messaging menu.

The problem with the current implementation is: NotifyOSD simply
*ignores* actions and it's up to the application developer to
explicitly include libindicate support in his app. Worse: he
can only do that if he can argue that his app fits in the
"messaging application" concept.

This has left this weird conceptual gap in the Ubuntu desktop,
where notifications that are persistent but not related to
messaging have nowhere to go, and things like Jockey, PolicyKit
and Apport are now as conceptually broken as they were before:
only now they use AppIndicators as their playground, instead of
the notification area.

(I think Apport was recently changed to use popups instead,
but I don't feel this is ideal either... it's not that urgent)

The Messaging Menu should be refined to support *any* persistent
notifications, not only from messaging applications. Only then
this conceptual gap will be closed. Until that happens, we will
stay either with legacy things like jockey popping up in the
indicator area or with strange things like Ubuntu One being in
the Messaging Menu.