All the desktop notifications on my (Ubuntu / i3) machine are handled by the notify-send binary and the Desktop Notification Specification -- except Ripcord, which seems to make its own balloons?

There's no such thing as a native notification system on Linux. notify-send isn't a standard. Ripcord uses the FreeDesktop spec for tray balloon messages, since that's what Qt uses.

by native he means the most used one which is https://developer.gnome.org/notification-spec/ and is implemented by libnotify. and it isnt tied to any gui toolkit.

Qt uses the tray balloon messages. I would have to implement the FreeDesktop notification spec myself and maintain the implementation myself. I don't really want to do that.

I've been evaluating Ripcord with Slack this week on my Fedora Workstation, which uses Gnome. Unfortunately, notifications don't work very well. While they do appear in Gnome's notifications centre, they appear two times (first saying that "application is ready", another with the actual message). Clicking on either of them only places focus on the window rather than selecting the corresponding channel in it as well. In general, the notifications don't look "native" either and they don't appear to persist.

In terms of implementing "native" FreeDesktop spec, I've done this a few years ago with Qt. It was a matter of invoking a codegen against the notifications D-Bus interface definition, then connecting to D-Bus and calling the RPC, optionally connecting to slots for notification actions via these generated code bindings.

There are libraries, like libsnore, that abstract various notification systems across platforms so that you wouldn't have to implement FD spec, growl, etc.

Native notifications can do a lot more than various legacy compatibility options for Qt's tray messages so please consider adding support for this. Would definitely buy the license if notifications worked seamlessly as otherwise I really like Ripcord.

libsnore is LGPL, so I do not want to use it in my own application code.

I realize the situation with notifications on Linux is not ideal. But some desktop environments have a way to adapt the tray messages into some other form of notification. KDE does this, for example.

If I implement the FreeDesktop spec, then people using something like elementaryOS will complain I didn't use their thing instead. The KDE people will complain I'm not using the KDE extensions. The people with customized DEs or people using tiling window managers will complain I'm not just 'shelling out' to notify-send since that's the only thing that works on their particular system, etc. No matter what I choose, people will complain I didn't choose the one they want.

The FreeDesktop notifications spec is common enough that I may have to do it myself, like you suggested above. I have been trying to avoid it, because it is a large burden that I will be stuck with forever. This includes maintenance, dealing with the dbus bindings/libs and Qt, testing it against multiple VMs and DEs on an going basis, etc., once I go down that path. It will slightly slow down every release of Ripcord I do in the future, because of the extra testing and checking I will have to do. I will have to keep more test VMs up to date and maintain them and keep the images working.

I understand your concerns, however please note that both KDE and Pantheon (elementaryOS WM) use FreeDesktop spec for their notification centres for a while now. The tray pop-up is a legacy compatibility option. So implementing the FD notifications will work out of the box for all the major WMs out there. The tray pop-up can be easily kept for compatibility in case the FD spec isn't supported on the currently running system (can be queried through D-Bus).

The issue with Gnome is that they deprecated the tray a year ago or so, which makes these pop-ups only available if you install a 3rd party extension (and still doesn't work that well).

Also please note that LGPL license allows dynamic linking without sharing the source code so that might still work for you.