GNOME Shell integration issue: infinite kalu icons (and processes) in GNOME Shell tray

[sza-1]

How to reproduce:

1. Run kalu in GNOME 3.x
2. Check output of "pgrep kalu | wc -l", perhaps count of processes will be 1
3. Wait when kalu displays a some notification
4. Click on the notification
5. Another kalu instance will be started
6. Check output of "pgrep kalu | wc -l", count of processes will be [1] +1
7. Go to step [3]...

Expected behavior: perhaps the notification should be closed. Or, maybe, the same action as for "Update System" button should execute.

[jjk-jacky]

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 of itself, which is what seems to be happening for you here whenever you click the notification. I'm not sure why, usually clicking the notification will simply close it, as does e.g. xfce-notifyd, but apparently here a new instance of kalu is started every time, so you end up with lots of instances of kalu running at the same time.

This is a behavior of your notification daemon (gnome-shell), so you should probably report it there and see how to fix it.

-j

[orschiro]

The issue still persists with Gnome 3.14., unfortunately. Has anyone found a solution in the meantime?

[sza-1]

I do not think that it is a bug of GNOME. I saw that author does not check notify_notification_close return value. It can give error information. Perhaps kalu uses libnotify improperly and Xfce (xfce-notifyd) ignores such kind of errors and close notifications but GNOME does not.

[jjk-jacky]

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 was successfully sent to the daemon, nothing else.

And regardless, kalu does not ever start a new instance of itself, and there is no reason the notification daemon should ever either (it's certainly not part of any spec, nor excepted behavior). Except for some reason, the GNOME daemon does.

I remember having a quick look through their code, and apparently on some event (click on a notification maybe?) if they don't find a window to make visible, they assume the app is not running anymore and start a new instance, or something similar. This is obviously wrong, app can be running without any windows; kalu does. Other apps do too (e.g. my mail client often has no windows, yet uses notifications on incoming mail).

GNOME devs decided to enforce a behavior that they surely feel is better, and will work with their own set of apps, but it will "break" in other cases, such as here.