Comment 14 for bug 390508

> Smeuuh, if we offered a configuration screen for something as boring
> as notification bubbles, we would have done something terribly wrong
> in the design. It's possible we have something terribly wrong, but if
> we have, it's a bug that should be fixed, not configured around.

Configuration is not always a sign of having done something
wrong. It's just a question of personal preferences, same as mouse
sensibility, or the delay between repeats on keypresses. All these and
even more have been configurable since time immemorial, and I don't
think anyone has ever complained about it.

I agree there is a thin line between what should be configurable by
default and what shouldn't, and maybe this is one of those case where
an additional option in preferences would be overkill. That may be so,
but in that case please provide a way to change it : an option in
gconf, honouring the timeout argument, a configuration file
somewhere ... just provide the option.

The problem here is that there are several classes of notifications,
which haven't the same importance to the user. The urgency setting is
a step in recognising this fact, but the granularity is just too
high. When my IM client receives a new messages, even with stacking, I
feel 5 seconds is just too much. I read fast and like just to glance
at the message to see what has been said, and go back to my IM client
if it needs further inspection. Some people with different use cases
might want longer notifications. The current state of notify-osd
doesn't allow me to set the timeout to a value appropriate for me
(which I could with libnotify, and which is an explicit part of the
protocol), and I feel that is a bug.

I haven't looked at the code, but I'd guess honouring timeouts would be pretty simple to do. I'm clearly missing something here, because I don't understand at all the point of not doing so, other than "the wiki page says so".