Written by badp the 29 Apr 09 at 17:26.

The program responsible for showing notification to screen should also write them on a log file. It would be useful to include the metadata such as priority or the program generating the notification.

Programs could parse the log file to display old notifications in a graphic fashion.

The program responsible for showing notification to screen should also write them on a log file. It would be useful to include the metadata such as priority or the program generating the notification. Programs could parse the log file to display old notifications in a graphic fashion.

Written by Ssdg the 29 Apr 09 at 19:48.

Why dont we use the double click on this applet to access a list (such as described in #1)? I think it's the better entry point to such a window.

Why dont we use the double click on this applet to access a list (such as described in #1)? I think it's the better entry point to such a window.

Written by Rodrigo the 29 Apr 09 at 20:19.

The MessagingMenu, the little "letter" with the green dot, could have a menu entry with the history of the last Notifications, that way it could be easy to see what happend while we were not paying attention.

The MessagingMenu, the little "letter" with the green dot, could have a menu entry with the history of the last Notifications, that way it could be easy to see what happend while we were not paying attention.

Written by andruk the 1 May 09 at 01:31.

I think that Growl supports "sticky" notifications, so the notification stays up, but I know that the design criteria for the current notifications scheme frowns upon notifications that don't get out of your way.

Instead, have the notifications that are "sticky" be logged in a history menu as in Solution #3. That way they are easily accessed. For example, notifications regarding which wireless network you're connected to do not have to be logged, but notifications regarding your friend instant messaging you (while you are away) would become "sticky".

Additionally, you could run the notification text through a user-defined regex so you catch all notifications that include certain words. A good example would be the word "meeting" - you don't want to miss a meeting, so all notifications that include the word (case insensitive) "meeting" would automatically become sticky and therefore they will all be logged.

I think that Growl supports "sticky" notifications, so the notification stays up, but I know that the design criteria for the current notifications scheme frowns upon notifications that don't get out of your way. Instead, have the notifications that are "sticky" be logged in a history menu as in Solution #3. That way they are easily accessed. For example, notifications regarding which wireless network you're connected to do not have to be logged, but notifications regarding your friend instant messaging you (while you are away) would become "sticky". Additionally, you could run the notification text through a user-defined regex so you catch all notifications that include certain words. A good example would be the word "meeting" - you don't want to miss a meeting, so all notifications that include the word (case insensitive) "meeting" would automatically become sticky and therefore they will all be logged.

Written by Psycho_zs the 3 May 09 at 07:03.

When clicked, this applet will show small terminal-like log of notifications.
Also this view could utilize same style as notification bubles and optionally replace them, showing short list of recent notifications in the same size as standard oversized notification, marking current line(s) in color.

When clicked, this applet will show small terminal-like log of notifications. Also this view could utilize same style as notification bubles and optionally replace them, showing short list of recent notifications in the same size as standard oversized notification, marking current line(s) in color.

Written by leggy the 6 May 09 at 23:49.

After the system has been inactive for a few minutes, keep notifications stuck on the screen. When the system is being used again, close the notifications after a delay. The delay should be proportional to the amount of stuck messages.

I think Growl has a similar feature.

After the system has been inactive for a few minutes, keep notifications stuck on the screen. When the system is being used again, close the notifications after a delay. The delay should be proportional to the amount of stuck messages. I think Growl has a similar feature.

Written by lavinog the 1 May 09 at 16:49.

To reduce the possibility that the user will be flooded with notifications upon unlocking, provide a way to ignore future notifications of each type.

A simple way to implement this would be to right click the notification and click ignore future occurrences.

To reduce the possibility that the user will be flooded with notifications upon unlocking, provide a way to ignore future notifications of each type. A simple way to implement this would be to right click the notification and click ignore future occurrences.

Written by eliteSchaf the 22 Oct 09 at 08:36.

A nice feature would be, if you click at the Indicator-Applet it shows a list of lately Notifications, which has been displayed by notify-osd which can bring the user to do something.

Examples:
"Package updates available", the User would usually start up update-manager and update the system

"Chris sent you a new message" (Pidgin), the user will open pidgin/chat-room and respond to him,
"A new Wireless Lan has been found. Would you like to connect to it?" and so on.

Notifications like "Battery full" or "Volume changed" should not show up in this list.

For example if a user clicks on the "Package updates available"-Entry, the Update-Manager could be invoked.

A nice feature would be, if you click at the Indicator-Applet it shows a list of lately Notifications, which has been displayed by notify-osd which can bring the user to do something. Examples: "Package updates available", the User would usually start up update-manager and update the system "Chris sent you a new message" (Pidgin), the user will open pidgin/chat-room and respond to him, "A new Wireless Lan has been found. Would you like to connect to it?" and so on. Notifications like "Battery full" or "Volume changed" should not show up in this list. For example if a user clicks on the "Package updates available"-Entry, the Update-Manager could be invoked.