mako taking over as notification daemon

Help
,
1

Good day.

I’ve been using KDE Plasma as my main environment for some time, but I have a backup Wayfire setup in case something breaks. I have also installed mako to use alongside Wayfire, however, it is now being launched as the notification daenon for KDE Plasma.

I’ve looked at the main answers for forcing plasmashell to be my notification daemon. Unfortunately, none of them suited my use case, or just didn’t work. Uninstalling mako would leave Wayfire without a notification daemon, and creating a symlink for org.kde.plasma.Notifications.service didn’t work either.

What other solutions could I try? I’m pretty stuck and also defeated somewhat. I’m guessing I should disable mako’s D-Bus service as an extra means of force, but I am willing to take more suggestions. Cheers :slight_smile:

2

I am going to guess you would want to stop the dbus service but have wayfire’s startup scripting load it instead.

Otherwise, you’d want to ask the mako folks about it.

1 Like
3

I might be started by D-Bus activation when the first notification is being sent.

For example I have /usr/share/dbus-1/services/org.kde.plasma.Notifications.service which tells D-Bus to start some Plasma component if any message is directed at the D-Bus notification “address” and no service as claimed it yet.

If Mako has installed a similar file and it is considered before Plasma’s then it might be started instead.

Temporarily moving Mako’s file to a backup location and restarting the session could check this theory

1 Like
4

Makes sense, especially if it’s sorted alphabetically:

dbus_services = [
    "org.kde.plasma.Notifications.service",
    "fr.emersion.mako.service",
]
dbus_services = sorted(dbus_services)
print(f"{dbus_services[0]}") # Output: fr.emersion.mako.service

As you have said, moving the service seems like the most logical things I could do here. I’ll ask since I am pretty conscious about messing with /usr. I want to make sure I can do this with /etc, ~/.config, or ~/.local/share. Cheers!

5

Using a local directory sounds like an interesting idea to test.

You could try by copying the service file for Plasma’s notification into ~/.local/share/dbus-1/services to see if it gets picked up earlier than the system location.

Another idea is to check if the D-Bus service files might also understand the NotShowIn or OnlyShowIn keys that .desktop files can have.

Something like NotShowIn=KDEin Mako’s service file

6

I have indeed tried this. I made a symlink to /usr/share/dbus-1/services/org.kde.plasma.Notifications.service in ~/.local/share/dbus-1/services/. However, it didn’t look like it changed much. I believe it could be due to this being the Exec= value:

Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications

I think mako is still being prioritised because it’s looking for whoever claims org.freedesktop.Notifications, rather than just loading with plasmashell. Curious why it’s like that.

7

It is also a bit strange timing wise.

Once Plasmashell has started it should have claimed the D-Bus name for notifications, so if D-Bus activates Mako instead it would suggest that something tries to show a notification before that.

Again all under the assumption that it is indeed D-Bus activation that causes this.
Temporarily “removing” the Mako service files would check that.

1 Like
8

Once Plasmashell has started it should have claimed the D-Bus name for notifications, so if D-Bus activates Mako instead it would suggest that something tries to show a notification before that.

This made me realise something. That is exactly what IBus is trying to do, I always get a notification upon starting KDE Plasma about some issue related to IBus. I can imagine that the root cause was just staring me in the face the whole way through. I’ll see if messing with IBus can help with that at least.

1 Like
9

Tried a few things:

  • Configured IBus (this caused the entire DE to not even work)
  • Moved around the mako D-Bus service (mako still launches automatically, disproving D-Bus activation)
  • Tested if I can disable it with systemd (The following unit files have been enabled in global scope.)

I am stumped.

10

Gotcha. I’ll see if making mako a dummy dbus file does anything. If not,
unfortunate, but I can try asking over on mako’s IRC channel. Cheers!