@Adrian Roman:
Weird analogy. You can do the same with notify-osd as you can do with other 
default applications: Replace it with an alternative from the repository if you 
don't like the feature set. notification-daemon would be an alternative to 
notify-osd that offers the features you want. Why don't you just go ahead and 
use that one instead?

Ryan J: 
> By reading the spec and following it.
That surely applies both ways, server and client side. Does your client follow 
"Clients should try and avoid making assumptions about the presentation and 
abilities of the notification server." ?
Besides that, that spec is a draft that is under revision anyways. People have 
expressed their unhappiness with specific parts (e.g. some KDE folks don't like 
clients being able to query server capabilities, as that breaks model/view 
separation etc).

@Marco Chiappero:
> And we don't really care about you telling us what's right or wrong for us.
I am not telling you what's right and wrong for you (who is "we"? Majestic 
plural?). I'm trying to tell you what notify-osd is all about. See above - if 
it doesn't fit your needs, use notification-daemon instead. That one respects 
timeouts, and is more configurable in general.

Alternatively, try to convince the notify-osd designers (I am btw not
one of these) that timeouts are vital. People do tend to change their
mind when something is well argued. It has been advised before that this
better be done on the corresponding mailing lists, as designers don't
generally read bug reports.

-- 
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

Reply via email to