Comment 18 for bug 390508

@Smeuuh: "merge" fixes the queuing of similar, overriding messages. Timeout control (which is what this bug is about) is still a problem.

@Matthew Paul Thomas:
> enb, Notify OSD does not implement timeouts at all, so it is not disabling
> them, and it is not "not disabling" them either. In Karmic, bubbles with
> short messages automatically stay up for a shorter time than long messages.

Then I ask again something that was asked above: why does the sound volume change get preferential treatment?

To me this means that the need for shorter timeouts is recognized as valid.

Except that developers seem to then add "yeah, but volume and brightness changes are the ONLY kinds of actions in the world that deserve these shorter timeouts". Which is silly.

We need custom timeouts. If you don't implement it, either someone else will, or it will stop adoption of notify OSD. It's that simple.

Personally, I'm trying to meet the original thinking halfway. I'm trying to figure out why make such a silly statement as the one above.

I'm guessing it's about how fast the average human can recognize information in the bubbles to make sensible use of them. Volume or brightness changes, since all they show is an icon and a slider, can be recognized very fast, hence the short timeout exception. Text needs to be read, hence a timeout which is adapted to the length of the text.

It is very sensible. Excepts it doesn't take into account situations which don't conform to this thinking. Such as outputting a very short piece of text with an explanatory custom icon. Basically, it's the minimum 5 second timeout that's the killer here.

So a way to meet us halfway would be to lower or eliminate the minimum timeout on text pieces. The fade in/out already adds almost a second going up+down. IMHO that's plenty of minimum timeout.