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:
"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:
"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.
>>mpt
No, it doesn't.
http:// www.galago- project. org/specs/ notification/ 0.9/x408. html#command- close-notificat ion
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.