@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
