KDE Notifications

One minor annoyance with KDE notifications is popups can be closed only by selecting the tiny Close button rather than clicking anywhere in the popup, which is the norm with other desktop environment notifications.

Ignoring that annoyance, KDE 5 Notifications remain a tad broken. Everything functions as expected within the user’s environment. Outside those boundaries notifications tend to splinter. Examples include system cron jobs.

Before using KDE 5 in the house network, for many years there never was a problem launching desktop notification popups as root or from cron jobs with the notify-send command. In KDE 5 that does not succeed well outside the user’s environment.

Computers in the house network depend heavily on cron jobs, SSH, and related popup notifications. For example, watching a movie on the living room media player is an activity where viewers prefer not to be interrupted. Yet sometimes a notification is helpful from an administrative perspective. The popups are configured not to linger perpetually and the popups help inform when something in the network needs attention sooner rather than later. System emails supplement this notification design but a popup tends to receive immediate attention.

Part of the problem seems to be that KDE 5 inherits some old design baggage. Years ago when the “desktop environment wars” first raged, there was an attitude of designing the desktop environment in an isolationist manner. Slowly that changed through the years and desktop environments became more compatible with one another. For example, with XDG standards.

Along with that old design is the dbus daemon is not well designed. The daemon is not designed to give a hoot about which notification daemon handles notifications. The KDE 5 notification daemon is ensnared in that poor design. Worse, the KDE 5 notification daemon does not seem to give a hoot about anything outside the user’s environment. Those system cron job alerts launched as root or through SSH never appear in KDE 5.

Experimenting found a solution. The first trick is ensuring a more robust notification daemon is installed. This is straightforward in Slackware 15.0 by installing the Xfce notification daemon. Because Xfce is part of a default Slackware install, this introduces no problems.

Next is ensuring the KDE notification service does not interfere. There is no easy way to remove the KDE notification daemon, but the KDE daemon can be ignored. That requires editing the KDE notification dbus service file, /usr/share/dbus-1/services/org.kde.plasma.Notifications.service.

The file cannot be deleted without introducing various notification issues. Easier is editing the file:

    [D-BUS Service]
    Name=org.freedesktop.Notifications
    #Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications
    Exec=/usr/lib64/xfce4/notifyd/xfce4-notifyd
    

One caution with this approach is configuring the root account with the same Xfce notification popup styles. This still does not fully render all popups to look the same. All of the popups launched from within the user’s environment will trigger the KDE popup window. Anything launched from outside that environment such as cron jobs or SSH will trigger the Xfce popup window.

Important though is no popups are ignored or lost in the ether. This hackish solution ensures that. With this nominal change all system-wide cron jobs and respective popup alerts function just like they have for many years.

Posted: June 17, 2023 Category: Usability Tagged: KDE

Next: KDE Dolphin Keyboard Navigation

Previous: KDE Countdown Timer