> 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 _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
