>>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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/390508 Title: notifyOSD ignores the expire timeout parameter To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/390508/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
