On 25/09/10 17:28, Dylan McCall wrote: > Attaching a sound hint to notifications is in notify-osd's > specification (and the desktop notifications spec). > > I put a patch implementing the feature here: > https://bugs.edge.launchpad.net/notify-osd/+bug/549900 > > As for tying together libnotify and the message indicator under Yet > Another library, I'm pretty worried about that idea. It would split us > further from upstreams (in a wacky, tangled way), increasing the > significant load of patches being applied and maintained within > Ubuntu. > > The notifications spec (as in libnotify) is pretty expressive, and I > get the feeling that it's completely wrong that all the > implementations use a single trick for presentation (a bubble), > leaving other methods of presenting that same information to other > specifications entirely. It's like buying an assault vehicle to get > the groceries. Hi Dylan Was this patch landed? If not, let's see if we can steer it home. For notifications generally, we definitely want the app to have more influence over the notification after it's dispatched it. For example: - we want the app to be able to associate a sound with the display. This has to be done through the notification system, since only the notification system knows when the notification will actually get displayed, and even though we want to tell the app, we don't want the roundtrip delay of a message to an app which then tells the sound system to play the sound. - we want the app to get an "about to show" callback when the message gets to the front of the queue (i.e. if it has been queued for a while as other notifications are displayed, it should this callback either when this notification is next, or perhaps when this notification as an estimated second left before display). So an app can update the text appropriately, or delete it from the queue, or change the sound associated with it. - we want apps to be better about appending / updating notification content, rather than just slamming new messages to the bus. For example, the sequence of "connected / disconnected" messages is disconcerting from NM, these should be *amended* in place, not queued. Mark
Attachment:
signature.asc
Description: OpenPGP digital signature