Xpra: Ticket #1735: notifications actions

Follow up from #1492, adding support for "actions" and "action-icons" optional capabilities.

Would also be nice to manage to:

Mon, 08 Jan 2018 06:50:17 GMT - Antoine Martin: status, description changed

Sat, 13 Jan 2018 06:16:07 GMT - Antoine Martin: attachment set

switching to the other ctypes implementation does not work: the structures are not equivallent

Sat, 13 Jan 2018 06:17:18 GMT - Antoine Martin:

Still todo: "actions"

Thu, 18 Jan 2018 06:41:33 GMT - Antoine Martin: attachment set

work in progress

Thu, 18 Jan 2018 12:10:43 GMT - Antoine Martin:

r18044 adds most of the code required.

Still TODO:

Fri, 19 Jan 2018 13:53:56 GMT - Antoine Martin: owner, status changed

(also some py3k / gtk3 fixes in r18056)

Turns out that it does work with gnome-shell but the usability is terrible (maybe they're trying to make so bad that they can claim the feature is broken then remove it, like they did for the systray?): you have to move away from the notification if the pointer is already there, then back over it to get the action buttons to slide down and reveal themselves... (why, oh why)

We can't implement "actions" on win32, as the NOTIFYICONDATA API is just too limited for that. We could switch to the GTK variant (as used on macos) for the notifications that require action buttons, but we would need to:

To test, run browser/xpra/trunk/src/tests/xpra/test_apps/test_system_tray.py:


From the systray that shows up, click "Send Notification" from the context menu. The notification should show up on the client with 2 options, each option should trigger a different ACTION_ID message on the server, ie:

notification_action(NOTIFICATION_ID, ACTION_ID)

Alternatively, this could be tested with any applications that uses notification actions. Note: this test app isn't useful on macos, because it seems that the systray forwarding doesn't work with right-clicks... (and with the python3 / GTK3 builds, not even left clicks..)

@maxmylyn: mostly a FYI.

Fri, 19 Jan 2018 19:02:13 GMT - J. Max Mena: owner changed

For reference my client and server are both Fedora 26 machines running trunk r18058.

So I decided to test this using Discord which is a popular internet messaging application (sigh, Electron based) that's focused on internet gaming. It's similar to IRC in that there's servers and channels and what-not. Anyways, Discord notifications totally break the client printing:

dbus[5087]: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_ARRAY && contained_signature && *contained_signature == DBUS_DICT_ENTRY_BEGIN_CHAR) || contained_signature == NULL || contained_signature_validity == DBUS_VALID" failed in file ../../dbus/dbus-message.c line 2998.
This is normally a bug in some application using the D-Bus library.
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

Thanks to some help with Jake I got a sample notification for you and piped it into a server log with -d dbus. If you need anything more specific let me know.

You can get the Discord application for Fedora here: https://copr.fedorainfracloud.org/coprs/tcg/discord/

Fri, 19 Jan 2018 19:03:51 GMT - J. Max Mena: attachment set

Server started with -d dbus - sample Discord notification piped into the server logs.

Sat, 20 Jan 2018 07:58:40 GMT - Antoine Martin: owner changed


Sorry, but I'm not going through the pain of installing some proprietary crap to figure out what it does with its dbus messages. Then registering and figuring out how this new proprietary protocol is supposed to be used. Just no. If the bug cannot be reproduced with an open source application I can actually use locally and dissect, then it does not exist.

Discord notifications totally break the client printing:

It would be clearer to say: "client, printing:"

BTW, your server log shows just:

org.xpra.Server.Event(connection-lost, ['22c21c9cb6a8b4831179b11e3cd31f43562530e4'])

Since it is the client that crashed, it is the log output from that side that we would need. (with as much detail as possible, maybe even "-d all").

Tue, 23 Jan 2018 17:40:24 GMT - J. Max Mena: status changed; resolution set

Sorry, but I'm not going through the pain of installing some proprietary crap to figure out what it does with its dbus messages.

I understand that, but Electron "apps" aren't going away anytime soon, even though I wish they would. But, I understand your trepidation at trying to debug something blindly.

However, it's not an issue anymore - it looks like r18064 did the trick. My client and server are currently at r18136 and the notifications no longer crash my client.


Sun, 18 Feb 2018 06:55:26 GMT - Antoine Martin:

Related improvements (loop detection, notifications, etc): r18468

Sat, 23 Jan 2021 05:32:24 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1735