Comment 5 for bug 390508

I'm sorry to say that this makes notify-osd unusable for certain applications, which need to control the timeout of the notification to smaller values as well as vary the placement and opacity.

IMHO, it should not be the job of the tool to decide how it is being used. If an application delivers "notification spam" people should take it up with the makers of that application. Enforcing artificial and subjective limitations in notify-osd seems to me quite the misplaced effort.

In the meantime, I suppose tools like aosd, xosd, gnome-osd etc. will have to keep being used. Which is a pity, since I was hoping notify-osd to be able to unify and replace them.

Back to the topic: it's still not clear to me, after reading the aforementioned docs, why certain bubbles (volume, brightness) are allowed to use shorter timeouts and stacking, whereas custom bubbles are stuck with sequential display and minum timeout of 5 seconds. It looks like the creators are perfectly aware of the need for stacking and shorter timeouts on occasions, but have just arbitrarily decided to make it a pain in the butt to access them(!) Why?

I respectfully urge the powers-that-be in charge of notify-osd to reconsider. I like the current timeout spec, but only as a feature. We need to be able to override it sometimes. This is a stringent, real need. Attempting to suppress it is, sorry to say, delusional, and will only lead to the appearance of patches that implement this.