"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.
--
notify-send ignores the expire timeout parameter
https://bugs.launchpad.net/bugs/390508
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
