Send notification locally from QT/C++/QML App.

pparent

@lk108 said in Send notification locally from QT/C++/QML App.:

@pparent Not sure if this is relevant here, but notifications won't show if the app is the currently active one, i.e., shown in the foreground with unlocked screen. This is on purpose: https://gitlab.com/ubports/development/core/lomiri-push-service/-/commit/0c8983a359e9834cad4015512d57b5a29ca06937

Thank's for the message, but I'm not sure to see what you mean by "notifications won't show if the app is the currently active one, i.e., shown in the foreground with unlocked screen."

In any case I would like yet to see a simple example where this notification system through POSTAL actually does work. The only example I've seen is dekko, but they have so many "notification plugins" modules in their code that it's very hard to follow what makes it work + they are running unconfined.

If someone knows how this systems works, and wants to write a minimal "Hello world" through notification example app, I think it could help many potential developers.

pparent

By the way intersting thing to note, having teleports and dekko installed

This does not do anything (but does not throw any error)

gdbus call --session --dest com.lomiri.Postal --object-path /com/lomiri/Postal/teleports_2eubports --method com.lomiri.Postal.Post teleports.ubports_teleports '{"message": "foobar", "notification":{"card": {"summary": "yes", "body": "hello", "popup": true, "persist": true}}}'

This triggers a notification

gdbus call --session --dest com.lomiri.Postal --object-path /com/lomiri/Postal/dekko2_2edekkoproject --method com.lomiri.Postal.Post dekko2.dekkoproject_dekko '{"message": "foobar", "notification":{"card": {"summary": "yes", "body": "hello", "popup": true, "persist": true}}}'

Why? Can anybody explain this witchcraft?

lduboeuf

@pparent said in Send notification locally from QT/C++/QML App.:

By the way intersting thing to note, having teleports and dekko installed

This does not do anything (but does not throw any error)

gdbus call --session --dest com.lomiri.Postal --object-path /com/lomiri/Postal/teleports_2eubports --method com.lomiri.Postal.Post teleports.ubports_teleports '{"message": "foobar", "notification":{"card": {"summary": "yes", "body": "hello", "popup": true, "persist": true}}}'

This triggers a notification

gdbus call --session --dest com.lomiri.Postal --object-path /com/lomiri/Postal/dekko2_2edekkoproject --method com.lomiri.Postal.Post dekko2.dekkoproject_dekko '{"message": "foobar", "notification":{"card": {"summary": "yes", "body": "hello", "popup": true, "persist": true}}}'

Why?

dekko is unconfined, teleports not....

pparent

@lduboeuf said in Send notification locally from QT/C++/QML App.:

dekko is unconfined, teleports not....

Yes but in both case I do the dbus call from unconfined terminal, so this should not even make a difference....

Or else, its Postal itself that when receiving the call, verifies if the app is confined or not, and will only send the notification if unconfined?.... This makes no sense at all....

If we can officially send notifications only from unconfined context then it should be clearly stated, but then it's to be expected that people want to build unconfined apps...

lk108

@pparent At some place in the code that generates the notification popup and the entry in the notification list, there's a check if the app for which the notification is generated is currently active and shown on the screen to the user. If that's the case, generation of the popup etc. is aborted.

lk108

@pparent Notifications has nothing to do with the app being confined or not

lk108

@pparent The DBus call passes the JSON at the end of your command to the so-called push helper. This is a separate executable that is shipped with each app that supports push. Check the manifest, it defines a hook "push" which has an entry "push-helper". This entry again references a JSON with an entry "exec" pointing to the push helper executable.

The push helper is called by the system with an infile containing the JSON passed by the DBus call, and an outfile to which the push helper is expected to write a JSON in a format that is understood by the notification service.

In the case of dekko2, the push helper is just passing the content of the infile to the outfile as it is already fed something in the correct format by dekko's background service. So your command works. In the case of teleports, the push helper is expecting something else entirely, and does not know what to do with the JSON that you fed to it via your DBus call.

lk108

@pparent For my app, this works: https://codeberg.org/lk108/deltatouch/src/commit/d734cab514c0ee0c465b759d46c05ada322f58ca/src/plugins/DeltaHandler/notificationsLomiriPostal.cpp#L345
(but only if the app is not currently shown to the user)

pparent

@lk108

Ok then let's agree on a minimalist example that should work. Can you see why this minimalist example does NOT work?

https://github.com/pparent76/UT-notify-example

It does not work, when dbus calls are made from the code, but it does not work either with the terminal command (Whether the app is visible or not when the call is made, it does not change anything)

gdbus call --session --dest com.lomiri.Postal --object-path /com/lomiri/Postal/notify_2epparent --method com.lomiri.Postal.Post notify.pparent_notify '{"message": "foobar", "notification":{"card": {"summary": "yes", "body": "hello", "popup": true, "persist": true}}}'

lk108

@pparent Three things:

In your manifest, you define a hook "notify-notify", but it should be "push":

[...]
    "hooks": {
        "notify": {
            "apparmor": "notify.apparmor",
            "desktop":  "notify.desktop",
            "content-hub": "content-hub.json"
        },
        "push": {
            "apparmor": "notify-push.apparmor",
            "push-helper": "notify-push-helper.json"
        }
    },
[...]

You need to install the push helper with execution rights in CMakeLists.txt:

install(PROGRAMS pushexec DESTINATION ${CMAKE_INSTALL_PREFIX})

I was not aware, but there actually seems to be a difference between confined and unconfined apps. The push helper of dekko is allowed to use cp, but for your app, it's not. So instead of the simple bash script that just says cp $1 $2, use python in your pushexec:

#!/usr/bin/python3
import sys
f1, f2 = sys.argv[1:3]
open(f2, "w").write(open(f1).read())

With this, your gdbus line works.

pparent

@lk108 said in Send notification locally from QT/C++/QML App.:

install(PROGRAMS pushexec DESTINATION ${CMAKE_INSTALL_PREFIX})

Ok it works!!! Thanks!

I guess this was the missing piece that I had seen nowhere else. ( Having PROGRAM instead of files )

I will make a version of whatsapp app with these notifications next.

Though, I still think this is not normal that it requires so many specific tweaks to do something as simple as sending a notification. At least my repo will possibly serve as a documentation for someone looking for that.

lk108

@pparent said in Send notification locally from QT/C++/QML App.:

I guess this was the missing piece that I had seen nowhere else. ( Having PROGRAM instead of files )

I found this by checking journalctl -f on the device while calling gdbus

pparent

Ok in this version of whatsweb I have the notifications working without being unconfined, and it gets to the system panel! (Provided the app is not suspended in background)

https://github.com/pparent76/whatsweb/tree/82cd0c659af09bfad4315ba6c39e398d881451c3

lduboeuf

@pparent said in Send notification locally from QT/C++/QML App.:

Ok in this version of whatsweb I have the notifications working without being unconfined, and it gets to the system panel! (Provided the app is not suspended in background)

https://github.com/pparent76/whatsweb/tree/778f2302414f75029b22ea42a136fce3440f7a29

congrats for your perseverance. Now you are in the perfect situation to update or create a documentation

pparent

@lduboeuf said in Send notification locally from QT/C++/QML App.:

congrats for your perseverance. Now you are in the perfect situation to update or create a documentation

Thank's I will make better than this! I will update my QML notification module, and make a scripts that installs into an existing project all the prerequisites for it to work. Because there are some many tweaks to achieve it that it should not be done by a human, it's a loss of time, and the risk of mistake is too high. And anyway a script is always a more precise documentation on the actions to take than a human readable documentation.

pparent

Ps: And by the way I also plan to make this whatsapp application way more usable than it was. The version currently on my repo, already include some improvements that make the app significantly more fluid, polished and usable. But I will keep improving it progressively, and I plan to fix all the major functionalities offered by whatsapp web, that are currently broken on the app (starting with downloading/uploading photos/videos). And also I guess that future upgrade to Qt6 will also be a leap forward in regards of performance of this app, given that the webengine will be significantly more modern.

Fuseteam

@pparent if you are going to improve the app further, there is one more idea you can try; whatsapp web's service workers.

If we can figure out the service workers, we can potentially get notifications even without being unsuspended

pparent

My solution to the initial question:
Here is my QML module to handle local notifications:

https://github.com/pparent76/UbuntuTouch-qml-notify-module

It contains a script setup-project.sh to install automatically all the requirements into the app project.

Also this push request to the whatsweb app can be pretty informative:

https://github.com/alefnode/ubports-apps/pull/44

Especially this commit that corresponds to setting up the module with setup-project.sh:

https://github.com/alefnode/ubports-apps/pull/44/commits/81d08baba14ed941ca0c9b246d0df543b0a452a6

pparent

@Fuseteam Seems out of my scope, and having notifications only when the app is on to me is not a real drawback, since it allows to get notifications only when you want, and quit the app otherwise.

Also in my current version I made a tweak to hide the webview when the app is not in foreground to make sure it does not compute any visual stuff in the webview in background.

In practice with this the battery usage seem very limited.

Fuseteam

@pparent that's an interesting tweak— curious to see the effect