Comment 222 for bug 390508

>>mpt

No, it doesn't.

http://www.galago-project.org/specs/notification/0.9/x408.html#command-close-notification

In section 9, notifaction D-BUS protocol specification, it clearly states:

"The following messages must be supported by all implementations. "

Following that is section 9.1, which lists several messages that are required to be implemented.

Among them, in subsection 9.1.2:

expire_timeout INT32 The timeout time in milliseconds since the display of the notification at which the notification should automatically close. If -1, the notification's expiration time is dependent on the notification server's settings, and may vary for the type of notification. If 0, never expire. "

Perhaps this is where design decisions for NotifyOSD began to go wrong: "If 0, never expire."

This specification presents a problem for Ubuntu's NotifyOSD design, which renders notifications with no means of closing the notifications manually. In fact, NotifyOSD renders notifications that don't accept any interaction at all:

http://developer.ubuntu.com/resources/technologies/notification/#Notification_actions

"Notify OSD bubbles cannot be clicked on themselves, nor can they contain buttons that can be clicked: in the terminology of the Desktop Notifications Specification, they do not accept actions."

Therefore, a timeout is the only means of closing NotifyOSD notifications, however a notification with expire_timeout 0 would never disappear, which is actually a problem with the freedesktop.org specification in that it allows non-interactive notifications with an expire_timeout of 0.

However, there is already logic in NotifyOSD to handle this specific situation:

http://developer.ubuntu.com/resources/technologies/notification/#Non-expiring_notifications

"Some programs specify an expire_timeout of 0 to produce notifications that never close by themselves, assuming that they can be closed manually as they can in notification-daemon. Because this is usually done for a message that requires response or acknowledgement, Notify OSD presents it as an alert box rather than as a bubble."

Furthermore "if a notification does not actually need response or acknowledgement, you can avoid it appearing as an alert box by setting the expire_timeout to the default value of -1." So NotifyOSD has to support expire_timeout by design after all.

There are no conflicts between fredesktop.org's specification and NotifyOSD's design that prevent a notification from dissapearing on a timer set by the program or script sending a notification. As there is no need to resolve the already resolved issue of non-expiring notifications, and no other conflict with the specification related to expire_timeout, and the design includes a use case for the parameter, there is no logic to support removing expire_timeout support from NotifyOSD or it's documentation.