@UBportsNews Is 24.04-2 supposed to be ready for click packages based on Qt 6 out of the box, i.e. without any Qt 6 related install_lib entries in clickable.yaml?

If so, the clickable docker images should probably be adapted to contain a Qt 6 dev environment (but this might have to be discussed with the clickable maintainers).

And a question regarding the lomiri-ui-toolkit snap: Any plans/timeline for lomiri-ui-toolkit-core26? DeltaTouch would really profit from Qt >= 6.6, but snap based on core24 only offers 6.4.

@mark1250 Did you have a lot of data in your home directory, like almost 50% usage or more?

The difference between Teleports on the one hand and Dekko / SMS on the other hand is that Teleports depends on the UBports push server for notifications, while notifications for Dekko and SMS are generated locally on the device. There's an issue in the lomiri-push-service repo regarding this. Although the issue mentions DeltaTouch, it should be the same underlying problem.

@UBportsNews Many thanks to Alfred for the possibility to encrypt personal data, really great! In the release notes of 24.04-1.0, it's stated that the feature needs to be enabled per-device, and indeed there seem to be some devices where it hasn't landed yet. How likely is it that the feature will be available for all noble devices eventually?

@Opolork Maybe some more tips regarding DeltaTouch:

• You are not restricted to the "Saved Messages" chat. To sort your stuff somewhat, you can create as many groups as you want with yourself as the only member. All these groups will be synchronized with all your devices running DeltaTouch or any other Delta Chat app that also have this profile (added as second device or via backup import).
• Check out Webxdc Apps: There are, e.g., editor apps, todo lists and shopping lists. Their contents and status will also be synchronized with the members of the chat (your devices only, if you are the only member of a group). These apps are running fully local, and except with the chat members, no data is shared with any third party or website. Just click the "+" at the bottom of a chat and select "Apps".

@peat_psuwit Thanks for the detailed explanation, very helpful! And the detection in the MR you linked is a piece of art.

@Keli It's not about the "Clear all" button, but about DeltaTouch removing the notification automatically, for example if you open a chat that contains the message for which a notification was sent.

@Keli said in Call for testing: Ubuntu Touch 24.04-1.1:

ush notifications work - I tested with DeltaTouch

However, clearing notifications does not work with DeltaTouch and 24.04-1.1 RC. We adapted to what we perceived as a change in the notifications DBus interface from focal to noble, but it seems this change is reverted in 24.04-1.1, so we need to revert as well, I assume.

@peat_psuwit said in Call for testing: Ubuntu Touch 24.04-1.1:

The Teleports update should not be needed for this to be fixed, at least in the specific case of Teleports.

In xenial and focal, the clearPersistent DBus method of com.Lomiri.Postal required the appid and the tag as a string. In 24.04-1.0, the tag(s) had to be passed as array of strings. Is it correct that this has been reverted and tags are passed as strings instead of an array of strings to clearPersistent?

@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 Three things:

1. 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"
        }
    },
[...]

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

install(PROGRAMS pushexec DESTINATION ${CMAKE_INSTALL_PREFIX})

3. 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 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 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.

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

@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.

@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

@oli.sax I asked regarding this in the "UBports Welcome & Install help [English]" Telegram channel back in April. Someone responded "oh crap i forgot to fix that". I did not follow up as it was not that important to me.

@Ced In the new release, the font size is configurable via settings.

@Schlicki2808 Ok, I can try to explain my thoughts regarding a dedicated background service/daemon, but I might be horribly wrong on some or all of it as I am just an amateur. Anyone, don't hesitate to correct me in that case.

After the latest release which features database encryption, it's quite easy: A daemon which is started automatically does not know the database passphrase, so it won't work before you start the app for the first time after booting. Using a keyring would solve this, but to my knowledge, there's no keyring in Ubuntu Touch at the moment that is automatically unlocked along with the device. In addition, users might want to use a stronger password for the database than the unlock PIN.

Even if database encryption is not active, it's still more difficult to implement than a daemon for Dekko because Dekko doesn't support encrypted emails. In contrast, encrypted messages are the default in Delta Chat/DeltaTouch. So the daemon would have to be able to read the database on the device, talk to email servers and decrypt the messages (to be able to show a part of the message in the notification). In my app, I did not program these tasks myself. Instead, the app uses libdeltachat (deltachat-core-rust) by the developers of Delta Chat. I just added the GUI and a little bit of logic. I don't have the skills and the time to re-write all of this just for a daemon, so it would make sense for a daemon to use libdeltachat as well. However, I think that libdeltachat doesn't have a read-only mode for accessing the database (again, I might be wrong on this). So when the app starts, the daemon would have to drop the database (easy), and when the app is closed, take it up again (no idea how to reliably inform the daemon that the app has closed).

Another possibility would be that the app uses the daemon to access the database. At the moment, that would require an extensive interface. In the future, however, libdeltachat functions will be accessed via JSON-RPC, so an inter-process communication would be a lot easier. I'm not sure though whether such a setup would be fast enough.

What's more, apps that run a daemon had to be unconfined in the past. Probably this will change (or has it already?) with focal though.

@Schlicki2808 Actually, it's me (Lothar). Great to hear that you like the app. Dekko runs a daemon in the background for notifications. There are some technical reasons why this is not so easy for DeltaTouch (let me know if you like to hear the details, it's a little bit complex). Maybe the situation will be different in the future as the use of the library provided by the Delta team that DeltaTouch is based upon will undergo some changes which might make a daemon easier to realize - not sure about that though.

For the time being, notifications depend a little bit whether you're on xenial or on focal. In any case, if background suspension is disabled for DeltaTouch, you will receive notifications if the app is running and in background. In xenial, disabling background suspension can be achieved via UT Tweak Tool. For focal, it can be done via command line (see below), or (as far as I know) a certain git version of UT Tweak Tool has to be build by yourself.

On xenial, if the app is in foreground, you will receive notifications for all accounts that are not the currently selected account (if in chatlist view) or, if you are currently viewing a chat, you will receive notifications for all conversations/accounts except for this specific chat.

On focal, UT currently suppresses any notifications for the app that is currently in foreground, I can't do anything about that.

Disabling background suspension in focal via command line (thanks to Danfro for instructions):

1. Fetch current suspended apps:

gsettings get com.canonical.qtmir lifecycle-exempt-appids

2. Add DeltaTouch to the list (the following assumes that the output of the previous command gave ['com.ubuntu.music'], please adapt to the output of your device):

gsettings set com.canonical.qtmir lifecycle-exempt-appids "['com.ubuntu.music', 'deltatouch.lotharketterer']"

@Ced I can make the text size configurable. Webxdc is not available yet. I'm working on it, but it may take a while.