[User Documentation] Wiki Page (and/or something) for Usage with Different Linux Desktop Environments?

[ThisNekoGuy]

I was looking for a way to target the notification system for KDE Plasma, without using notify-send, when I came upon toastify.

Investigating how to use it with specific options (like KDE Plasma's "persistence" feature which keeps notifications in user-viewable history), I found that it was very difficult to identify the use of these features and providing a way to clarify this (and add it, if not currently accessible) would be very helpful.

In my example, I was expecting to be able to use these features:

neko-san@ARCH ~> toastify info
server information:
 ServerInformation { name: "Plasma", vendor: "KDE", version: "5.23.4", spec_version: "1.2" }

capabilities:
 ["body", "body-hyperlinks", "body-markup", "body-images", "icon-static", "actions", "persistence", "inline-reply", "x-kde-urls", "x-kde-origin-name", "x-kde-display-appname", "inhibitions"]

neko-san@ARCH ~> 

but found that I either couldn't use them or that the knowledge necessary to use them was inaccessible to me.

[hoodie]

Hi there!
Yes the spec is a bit unclear sometimes and the different desktop environments interpret it slightly inconsistently.
I've found that the timeout flag works relatively reliably.

So for a "persistent" notification you should be able to go timeout=0

here it says:

The timeout time in milliseconds since the display of the notification at which the notification should automatically close.
If -1, the notification's expiration time is dependent on the notification server's settings, and may vary for the type of notification.
If 0, the notification never expires.

So in toastify terms you shoud set --expire-time 0

[ThisNekoGuy]

I mean, that sort of works, yeah but that's also the equivalent to:
notify-send 'Task Complete' --app-name=wget --icon=media-downloader --urgency=critical
(urgency=critical)

This only makes the timer never expire instead of never logging it into Plasma's notification history; which isn't bad by itself, it does guarantee the notification is seen, but in a hypothetical scenario where there's "too many" notifications: this method would fail because Plasma will just start throwing away notifications to make space for new ones (or the old ones - I forget) on-screen...

This, of course, is less likely to occur with direct average user usage but it's still feature I generally rely on so I don't forget things (sometimes I just want notifications out of the way but don't want to completely forget they existed, thus the notification history); which is part of the reason why I was looking away from using notify-send in the first place

[hoodie]

Oh sorry, I think I mistook your original issue then. So what you are looking for is "how do I do things in general"?
So this tool basically just provides the means to create and send a notification to your desktop environment right, and it does so in a specified fashion. The specification is supposed to be linked here but I'm surprised to see that the link is actually currently dead 😨

Even the KDE page links there.
[The spec] is very generic, so what exactly happens visually is a bit up to things like GNOME and KDE themselves, and it may actually vary slightly from version to version.

Technically toastify does nothing different than what notify-send does, it sends an org.freedesktop.Notifications notification via dbus and hopes for the best.
There might be better documentation in the KDE or Gnome communities and if you find some, I'd love to link to it.

Sorry if I'm not very helpful here

[ThisNekoGuy]

Oof, okay

That's odd though; I'll try to see if I can ask in the KDE matrix chatroom about it (don't know if I'll get an answer though) and link them here so hopefully they can fill in that gap

Thanks for clarifying 👌