Comment 94 for bug 390508

"You just cannot rely on specific timeouts, or specific behaviour. In fact, you can't even rely on your notification being visible at all. The notification daemon could just as well not display anything, but write the message to a log file (which obviously never times out)."

If the only guarantee is that notifications get sent 'somewhere', then what's the point of even having it? Are you saying that anyone developing an application that needs to provide visual notifications to their users shouldn't use any of the notification daemons _at all_, because that's what it sounds like to me?

"How does a developer know how his notification is going to look or behave?"

By reading the spec and following it. That's the reason I've posted in this bug report. In my opinion the notify-osd developers ignored part of the spec and, because notify-osd is in Ubuntu, everyone else is forced to work around their _opinion_ of a suitable timeout value or to ignore Ubuntu which is a much worse option.

I use notify-send with a single script that rsyncs some data once every 5 mins. When the script runs successfully I use a 3 second notification. When it fails I use a 15 second notification. I want both to be relatively unobtrusive, but (in my opinion) it's more important to see a notification about a failure condition than it is to see one about success.

I still want a notification when my script runs successfully, because I want to _know_ that it's running. If it's running properly I don't mind missing the (short) notification two or three times in a row and, since I'm used to seeing it, I can read it in about 2 seconds. However, if it fails I'd prefer to see the notification as soon as possible and want a little more time to read it (definitely more than 5 seconds).

Is there another solution better than notify-send that I can use that will push an unobtrusive notification to my desktop. Keep in mind my script took about 60 seconds to write. Am I mis-using notify-send?

Completely ignoring the argument of what is required by the spec, I think it was a poor design decision for notify-osd to make _all_ notifications so similar looking. As a user I want (critical) notifications about something failing to stay on the screen longer and have a more prominent look to them. I can't be the only user that takes more time to interpret a failure condition (that I rarely see) than I take to interpret a success condition (that I'm expecting because I see it all the time).

I've also seen comments suggesting that allowing a longer timeout will allow developers to block notifications from other applications by setting a long timeout value. I can already cause considerable delay by sending multiple messages to the daemon in short succession. Ex:

for i in {1..3}; do notify-send "Hello World $i"; done

Had I not taken the time to patch notify-osd, the above would have been my solution for displaying a longer notification. Is that the kind of behavior anyone wants to encourage? I'd think that adding some spam control to the notification queue would be more important to the users' experience than forcing all notifications to use a 5 second duration.