Tickets :: Comment on [#9950] Broken notification in compose window

* Your Email Address
* Spam protection	Enter the letters below: . ..___.. ..__.. . \|\ \| \| \|__\|[__]\|\ \| \| \\| \| \| \|\| \|\| \\|
Comment	>> And they are raised several times if you had several notifications >> piling up. Though this might be a problem of audio notifications not >> being used in the main interface. It makes them pile up, and they are >> all outputed at once (making a terrible noise) if you open a page >> that supports audio notifications. I'm not sure if we should >> implement a duplicate check in the audio notification listener. But >> for now we should either support audio notifications throughout DIMP >> or check for duplicates where we output the notifications in DIMP. > > I think this issue is more of a fundamental flaw (or, at least, a > limitation) in the current Notification system. At present, there > really is no way to push a notification with the intent of "I want > the notification to be displayed on this page access and, if not, you > can go ahead and discard the notification". Especially for things > like newmail notifications, this is time-critical information. It > becomes useless once the page access is complete. > > I've worked around the limitation in IMP (somewhat) by using > Decorators. Decorators were used simply because they are triggered > whenever notify() is called. Thus, I only create notifications if I > know the notifications are about to be displayed. > > However, an alternative method would be to indicate, at the time we > are pushing the notification, whether the notification should persist > in the session. (Although an advantage of doing the Decorator > approach is to prevent potentially costly activities, such as mailbox > polling, when there is absolutely no chance it would be used on a > page).
Attachment
Watch this ticket

Saved Queries