Comment 140 for bug 390508

"bealer, opensource based doesn't mean you can't take design decisions or choices, we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, it's what other very people device makers do for their system as well and users don't complain so much about the limitations since in the end it leads to things working nicely together in a consistent way"

Of course decisions have to be made, that's what this whole argument is about. People arguing the wrong decision has been made.

Being open source and community based just means people can contribute fixes/patches (as per above), and also give feedback and be involved around these decisions. That seems to be lacking in this case.

Decisions should be based on feedback. In this case from developers and users in terms of experience. At the moment developers are crying out for this feature. We don't know how users will be affected, because I would guess it's not been tried. There's nothing stopping you opening it up fully, and if it becomes abused, updating notify-osd so that timeouts can no longer be specified, or as I mentioned implement a few different levels of duration.

"The vast majority of people out there don't care about notifications"

Then let us set it to whatever we want!

"They don't want to understand why some of the messages coming are different or to configure every softwares to behave different, that should just be working on be out of their way"

They're not inclined to understand in many of the examples given. People have given examples of when overriding would be beneficial and improve user experience.

In the case of the screenshot example, I think the user would be more inclined to think/ "understand" why the notification pops up for so long, or is included in the screenshot (not understanding that the dev that wrote it had no control over it), as opposed to if it came up quickly.

With a notification app, you need to think how it's going to be used. We've defined plenty of use cases above. And from example use cases define an appropriate public interface. Not define how it should work, then try to fit the use cases around it. That's awful design and will either lead to poor user experience in the examples given, or people developing the same thing twice, so that they can open it up more.