No it not call.. Also not send notification again.
output:

okay, this one should work better: https://dl.dropboxusercontent.com/u/...-1.armv7hl.rpm

Yeee, now it's better, but still have problem.
1. after installation it not send notification, I need first to open app.
2. By pressing on notification it start call to voicemail like it should be, but if you hang up without listen your message, it not send notification again.
It should send notification untill user will listen to all voicemessages, snd app will see "false" instead "true".

1. Old daemon is still working
2. It's not watching where you calling.
No it shouldn't. <Can be> (possible) and <should be> is different things.

I wrote "should be" because of behavior of Zeta patch, that user can't remove notification icon until user will listen to all messages.
If you can implement it (sendinding notification until user will listen to all messages) will be GREAT! Pleaseeeee !!!!

No it's not possible. t can be used only with addition to lockscreen patch.

Why? After pressing on the notification it stop to listen to false/true outputs ?

I did now another test..
I have 2 voice messages that I didn't listen yet. In previous post I wrote that when I pressed on notification, phone call to voice mail and I hang up. That mean 2 messages still here.
Now I call to myself and leaved new message (#3), but app not send me notification

Update: after listening all messages I leaved new one and in this condition it send new notification. But also when you remove notification by pull down -> clear notification (without call to voicemail) it not send new notification.
That mean we can see this notification only once, and if user remove this witbout listening messages he will not get new notifications if people start to leave them from this moment.

That is expected.

When polling, you are looking every time if there is an event. But polling is not efficient (battery-wise and CPU wise).

So here, the approch is to use events that are sent when the status is changed.
It is basically what happens in my QML patch but it is hidden behind the QML logic (to map some properties from the image to another object, here the ofono component).
This works great in the QML patch, simply because the user cannot do anything about it.

With notification, there is an additional problem : the user can delete it. If the app is not aware of that, then it waits for the next change of status. It was true, so it waits for it to go to false, which is only possible by reading the voicemails. If you add a second message, then it will still be true, so no change, so no new notification sent. If the count was good, we would see a change here, but it is always 0 in my tests.
There will always be this limit that we can not know if a second message is left, we only know that there is at least a message.

So, the problem we "need" to solve here is : how the app can know that the notification has been deleted by the user and the voicemail has not been read ?

Hopefully there is a solution (I think of 2, but didn't tried any yet):

idea 1) keep a link to the sent notification, to know it has been closed.
The notification object can return a signal when it has been closed. In the nemo plugin for notification, this is done like this:
https://github.com/nemomobile/nemo-q...ation.cpp#L475
https://github.com/nemomobile/nemo-q...ication.h#L119
This emits a signal called "void closed(uint reason);" where reason is :

• 1 if the notification expired,
• 2 if the notification was dismissed by the user,
• 3 if the notification was closed by a call to CloseNotification.

That way we can trigger a 20 seconds (for example) timer, to leave some time after the guy closed the notification (either by pulley menu or pressing it which calls the voicemail) to check the state manually, and send the notification again if it is still here.
If the guy is still on the phone reading the voicemail and deleting it several seconds later, we will still have the change notification, so it is ok and notification will be removed.

Idea 2) make the notification not removable by the user.
I've seen that somewhere in the doc. If the user can't do anything about the only way to remove it is to actually read the message. No more problems, back in the QML patch case.
I've never tried this, but here is where I read that :
https://github.com/nemomobile/nemo-q...ation.cpp#L272
And searching in the web, found this one too:
https://github.com/nemomobile/lipsti...anager.cpp#L65
Follow the symbol HINT_USER_REMOVABLE inside the file to see how it is used by lipstick.
This looks like non-standard in freedesktop.org definition of notifications, but something present in lipstick, so we could try this.

No time to test this today. If anyone wants to try, I am waiting for the feedback !

I think the first option preferred because in second option you can't call to voicemail by pressing on the notification, because it not removable.