Hello there,

I am creating a Desklet for the Cinnamon DE to interact with KDE Connect and show various information about a connected device(usually phone) like battery state, name and notifications.
To interact with KDE Connect i am using DBus and after updating to 1.4, I saw that there are new features such as Notification Actions, which are displayed in desktop notifications as buttons.omegle xender

I wanted to impliment this functionality into my Desklet, so I looked at the DBus methods and found a sendAction method which requires a key and an action variable.

My Problem is, that I don't know where I should get the key and action variables from. For the sendReply method I cound use the replyId property. I saw, that there is an internalId property, but I don't know if that's useful.

I hope someone can help me. Thanks in advance.

fabianallen wrote:Hello there,

I am creating a Desklet for the Cinnamon DE to interact with KDE Connect and show various information about a connected device(usually phone) like battery state, name and notifications.
To interact with KDE Connect i am using DBus and after updating to 1.4, I saw that there are new features such as Notification Actions, which are displayed in desktop notifications as buttons.omegle xender

I wanted to impliment this functionality into my Desklet, so I looked at the DBus methods and found a sendAction method which requires a key and an action variable.

My Problem is, that I don't know where I should get the key and action variables from. For the sendReply method I cound use the replyId property. I saw, that there is an internalId property, but I don't know if that's useful.

I hope someone can help me. Thanks in advance.

This reply might be a bit late, but I've been bashing my head up against DBUS notification actions since yesterday and happened to notice your question. My experience is confined to python, but I imagine it parallels what would be done in other languages.

The "key" is the notification ID that is returned when a notification is first raised. The action ID is also passed when raising the notification. Some code:

Code: Select all

    message_id = notify_interface.Notify('myapp',
                                         0,
                                         'dialog-error',
                                         'my title'.encode('UTF-8'),
                                         'my message'.encode('UTF-8'),
                                         ['myActionId', 'My action', 'mySecondActionId', 'Second action'],
                                         {},
                                         0)

The DBUS API you are using should provide some means of registering a callback to handle actions:

Code: Select all

        def notification_action_invoked_handler(*args, **kwargs):
            debug('notification_action_invoked_handler', args)
            message_id = args[0]
            action_id = args[1]
            debug("action for message_id", message_id, action_id)

        self.notify_interface.connect_to_signal("ActionInvoked", notification_action_invoked_handler)


The above examples are based on code in https://github.com/digitaltrails/procno, a process monitoring tool. I just pushed some changes that add notification actions, so you can find working code there if you need it.

The other thing to be aware of is that testing this kind of code can mess up the DBUS notification system (at least when using KDE). For example, if you pass the wrong/unexpected notification ID, whatever is handling the notifications for the desktop can become confused, it won't fall over, but it may swallow messages, and it may even duplicate them. In the case were existing notifications are being updated, the updates may not appear, or may appear as new/separate messages. Once the notification system is confused, I don't think it can be cleared. So if the results of testing suddenly become erratic, it may pay to reboot (or logout and check that no processes/sessions remain - telinit 3 then 5 perhaps). In the end it may pay to test such code in a VM, I'm using VirtualBox.

Note also, that not all notification capabilities are supported by all desktops, for example, Deepin does not support updating notifications, but it does support actions. So it pays to test anywhere you might like to deploy.

[Quick edit - if I use both actions and persistence (updating existing notifications) things seem to eventually run off the rails in the manner described above - so I now don't use both at the same time.]