unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

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