Follow up from #1492, adding support for "actions" and "action-icons" optional capabilities.
Would also be nice to manage to:
switching to the other ctypes implementation does not work: the structures are not equivallent
Still todo: "actions"
work in progress
r18044 adds most of the code required.
Still TODO:
(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:
./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.
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/
Server started with -d dbus - sample Discord notification piped into the server logs.
Updates:
XPRA_NATIVE_NOTIFIER=0
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").
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.
Closing.
Related improvements (loop detection, notifications, etc): r18468
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1735