Olivier Brunel

Well, it's not as easy as you seem to think/make it out to be I'm afraid. That call to alpm_option_set_fetchcb() you link to does set a function as callback, one...

There's been talk about an option to do that on pacman-dev ML[1], it hasn't happened/been applied yet but maybe you can apply the patch in the mean time - though...

Absolutely, I intend to.

Well, that does sound pretty bad, but I believe this isn't a bug in kalu, but gnome-shell (or whatever handles notifications in GNOME). kalu doesn't ever start a new instance...

No, I believe it is a bug in GNOME. The return value of notify_notification_close() is irrelevant, it only indicates whether or not the "order" from kalu to close the notification...

Thank you!

Applied (w/ only slight changes to commit message), thanks!

hmm, I'm not sure about that. When you re-run checks (or re-show notifications) it means to create new notifications. Especially since whether or not the previous ones still exist/are kept...

Yes, I understood what you meant, I'm just not sure this would be the right thing to do. What I'm (trying to) say is that it doesn't seem to me...

Well, in Preferences you can set a timeout after which notifications expire/should be auto-closed, so you shouldn't get a pile of notifications that way -- unless your notification daemon keeps...