I’m unsure if this is expected behavior related to notifications, hence why I’m not on bugs.kde.
When lacking the notification tray icon, any attempt to push a notification will await the full timeout period.
This is causing issues with a few messaging based applications on my desktop, as they will hang for the duration of the timeout period. (60s). Multiple notification pushes will build up an event queue within applications.
If this is unexpected behavior, I suspect an easy solution may be to check if the user has the notification widget and returning instantly in the case that they do not.
To test/reproduce, remove all notification widgets and use notify-send via your terminal of choice.
I guess there are two things that need to be checked here
Why does the sending application hang? That shouldn’t happen even if the service does not respond unless the application explicitly blocks for an answer.
Assuming the blocking behavior doesn’t happen, what should happen for the user?
Should the notification be displayed in some fallback location
Should some other notification provider (if available) be tasked instead of Plasma
I guess I really should specify - the application is discord, so an electron app.
Logs for discord show that the error is more specifically from the dependency libnotify through a directory for electron.
There are two error messages that result from not having a notification widget:
“Timeout was reached”
“Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached”.
I tried notify-send after seeing these and received the same “Timeout was reached”.
The latter message seems to stem from plasma_waitforname.
I suspect that discord has an await on their Notification function. I would imagine in the instance of no notification provider, it would likely be okay for an application like discord to not push notifications.
Hmm, I guess libnotify has, for simplicity, only a synchronous API and the application can’t really do a “fire and forget” but has to wait for the response.
The second error suggests that Plasma has, probably correctly, ceased to be registered as the notification host provider, so D-Bus tries to activate one when it gets the request.
Which then fails and results in the timeout for the caller.
Could you try
busctl --user | grep Notification
to verify that Plasma does indeed not hold that name anymore?
I get
org.freedesktop.Notifications 2550 plasmashell kevin :1.30 user@1000.service - -
but of course I do have the notification icon in my system tray
Genuine question - would it be unreasonable to use a separate thread to wait for the notification provider? That way if it hangs at all it’s not on main thread
Ok, that seems to verify that Plasma does no longer claim to be the Notification host when you remove all related widgets.
Which means the client could probably have detected that.
I guess Plasma would also need to “disable” its D-Bus activation data, so that D-Bus would not try to reinstate it as the Notification provider and instead either launch a different one or fail more quickly.
The question is, what did the user intend when they removed the notification UI element?
Just didn’t want to show or did not want any notifications at all?
That would definitely be possible. The app can also decide not do to blocking calls.
D-Bus is inherently asynchronous and low level APIs support that mode of operation.
Higher level APIs, here libnotify, sometimes only consider synchronous calls for simplicity.
Both switching to an asynchronous API or using a thread would both help. Which one to use is likely a preference of the developer, their framework’s capabilities, etc.
In my case, it was as simple as accidentally removing it while trying to customize other items in the panel. I would imagine that some user may remove the widget as a method of preventing notifications, that sort of goes against the DND slider within though.
I feel like Discord’s synchronous behavior surrounding pushing notifications is perhaps the least expected since they’re likely using JavaScript. I see the argument that libnotify should also make the call asynchronously.
While they’re might be some take-away here for a future KDE update, I think it’s much more likely that this is something that needs to be considered either from discord or libnotify… Would you agree?
Maybe we need some additional warning if this deactivates notifications alltogether.
There could also be the use case of using a different notification provider.
Probably not as likely but the current behavior (Plasma unregistering on D-Bus) would support that or at least partially because D-Bus activation will likely stlll consider Plasma a viable candidate.
The question is how their JS API is implemented.
For example they might be using the Web Notifications API which means this is using the integration provided by the Chromium engine. It would then need to use non-blocking D-Bus calls instead to map this to non-blocking JS.
You could check how a Chromium based browser behaves when a web page uses that API.
It was likely intended to be an easy to use convenience wrapper.
And notifications are kind of “expected to be present” because all desktops implement it and D-Bus can autostart such a service as long as any is installed.
I think you only ran into the timeout because D-Bus attempted to “start” Plasma but its internal configuration said “don’t be the Notifications host”.
Yes, ideally they would not block, or in the case of libnotify offer both.
Realistically they will assume that the platform has notifications and just consider systems without to be “unsupported”.
A user removing all UI elements for notifications in Plasma is probably still something the Plasma team would want to look into.
Either as something that should not happen or deciding how to make the user aware that they will likely experience issues.