I don't have the background or knowledge to understand the reasoning underlying the design decisions behind notify-osd so I will refrain from demanding design changes, even though it seems a little bit peculiar that having a configurable time-out (with a max-time perhaps) could hurt that much.
But, from a use case of view there are two very different scenarios that fits the use of notify-osd and demands different time-outs:
1. "Un-solicited" notifcation (for example, mail arriving)
2. "Pop-up response" use case (for example, outcome of runned script)
In the first case, a longer time-out is justified in order for the user to notify it, but in the second case, where the user watches the screen, waiting for the response, the long time-out is annoying. I bet 95% of all complainers use the notify-osd as in the second example.
These two use cases would require different time-outs.
I don't have the background or knowledge to understand the reasoning underlying the design decisions behind notify-osd so I will refrain from demanding design changes, even though it seems a little bit peculiar that having a configurable time-out (with a max-time perhaps) could hurt that much.
But, from a use case of view there are two very different scenarios that fits the use of notify-osd and demands different time-outs:
1. "Un-solicited" notifcation (for example, mail arriving)
2. "Pop-up response" use case (for example, outcome of runned script)
In the first case, a longer time-out is justified in order for the user to notify it, but in the second case, where the user watches the screen, waiting for the response, the long time-out is annoying. I bet 95% of all complainers use the notify-osd as in the second example.
These two use cases would require different time-outs.