Comment 3 for bug 445289

> Correct. This part was changed on the ground that it was breaking a
> basic design principle of n-osd to manage a queue of notifications and
> avoid "rushing" the user.
>
> From a protocol point of view, we still honor the call and return a
> success value. However, the notification is /not/ immediately closed.
>
> However, I think we could remove a notification from the queue, if it is
> not already on display.

I understand your design decision, but I think that the application that
created the notification should be able to close it as well - even
though it was already on-screen.
In most cases it should be enough to update the current notification,
but there are some cases where this is not enough.

For example: I am developing a screenshot taking application (Shutter)
and I want to use notify-osd (or any other daemon that supports the
protocol) to display some status information or hints. If the user takes
the next screenshot it is very important that the last message shown can
be closed reliably to avoid unwanted messages to be on the screenshots.

Don't get me wrong - I don't want to manipulate the queue and I don't
want to close foreign notifications but I want to have some control over
my own notifications.

Due to the fact that there is no window (the main window is hidden when
taking a screenshot) to display any information notify-osd looked like a
very good solution for this.

Please reconsider this decision.

Regards
Mario