Talk:Desktop notifications

From ArchWiki
Latest comment: 30 June 2020 by Danuker in topic Notification server problems - dbus

Clarification on setting up standalone environment

I just went through this for the first time and found this bit confusing:

""" In other desktop environments, the notification server needs to be launched using your WM's/DE's "autostart" option.

It can also be launched on the first call via D-Bus, adding the following configuration to its services directory /usr/share/dbus-1/services respectively $XDG_DATA_HOME/dbus-1/services, e.g.

[D-BUS Service]


I expected /usr/lib/notification-daemon-1.0 to exist, but it didn't. I also didn't see any systemd units containing "notif." In the end, I was able to install dusnt and things just worked when issuing notify-sent "test", which would indicate that that section might be either/or? If so, that would be awesome to clarify. Maybe dbus setup is one way, *or* you can install one of the other packages. Since dunst mentions it takes dbus notifications, I assumed I needed to do something to get it to work. To my knowledge, I haven't. If there is such a step, perhaps that check could be cited as well (e.g. "To ensure things are setup properly, issue this command and check for this output."). There's surprisingly little out there about notifications and openbox, so it would be great for this to be a comprehensive source for others! Jwhendy (talk) 23:23, 1 January 2018 (UTC)Reply[reply]

D-Bus .service files are not systemd units. (Secondly, in both DBus and systemd, user services are fully separate from system services.) grawity (talk) 23:34, 1 January 2018 (UTC)Reply[reply]
Alright. Now that dbus vs. systemd is clarified, should I have a /usr/lib/notification-daemon-1.0 directory? Or is the statement "the notification server needs to be launched" accurate given that I didn't do it and things worked with dunst? Or should the page differentiate "dbus vs. the options below" if they are independent? I'm just trying to have a discussion about whether or not the page is as clear as it could be. In my view, the wiki is providing education to users. I am a novice user of this particular topic and it wasn't clear. I'm trying to have a discussion about that. Jwhendy (talk) 23:43, 1 January 2018 (UTC)Reply[reply]
That directory is just for the "original" GNOME Classic notification-daemon. All the other implementations (xfce-notify, dunst, notify-osd...) are independent and install to different places.
Yes, those two options are independent. DBus .service files are only an autostart mechanism, not needed for the service to work in general.
The fact that there are several implementations of the same service means it's recommended for the DE/WM to launch the correct implementation manually, and they all should not install DBus .service files for autolaunching (because if you install multiple, it's impossible to choose which one gets autolaunched).
Though dunst goes against this recommendation and installs a .service file anyway, so as a result running notify-send autostarts it for you. grawity (talk) 05:34, 2 January 2018 (UTC)Reply[reply]
Cool, and thanks for the clarification. Would you like me to take a stab at updating slightly based on this? I feel like an easy fix would be to just move dbus after the bit about "you can choose one of the following implementations." It sounds like it's just another way you can do this and thus would make sense grouped as an alternative vs. a standalone preface.
I still don't understand if I should have /usr/lib/notification-daemon-1.0/notification-deamon? It seems like I should from the article (Exec=foo), so I don't understand what it would be running.
I did have to start dunst, then run the command. Sorry for the confusion. I meant that I did nothing with dbus and dunst worked independently. But you've clarified that, now, so we're good re. the other options. Jwhendy (talk) 17:31, 2 January 2018 (UTC)Reply[reply]
/usr/lib/notification-daemon-1.0 is not a shared path – it is just a notification daemon, one of many. (You're basically asking: "Should I have /usr/bin/firefox if I want to use Chrome?") So if you only have Dunst installed but not notification-daemon, you won't have that file, and you won't need it. In your case, the D-Bus service would be /usr/bin/dunst. grawity (talk) 17:40, 2 January 2018 (UTC)Reply[reply]
I don't think that's what I'm asking. I wanted to understand what the dbus section was even talking about. I think now I get it: it's an example of an alternative to, e.g. adding the service to one's WM config (like .config/openbox/ It was not clear to me that this was an example file to create for the notification-daemon package. It's mentioned before that whole list, so I thought it was some way to use some built-in function of dbus to set this up. Imagine if the sentence read: "For example, if using the notification-daemon package listed below, one would create a file like this:" That would have answered all my questions. I didn't want to find notification-daemon given using dunst... I moved on to dunst because I didn't know that section was even talking about. What do you think about the change above? Jwhendy (talk) 18:01, 2 January 2018 (UTC)Reply[reply]

Notification server problems - dbus

I am using the MATE DE, but I have installed and tried KDE Plasma. Some applications, for example Skype for linux and Thunderbird freezed from time to time. I did not really like it, so I went back to Mate. But skype was still freezing, so after some searching on the net, I have disabled the notifications. Finally, it turned out that the reason was that the notification daemon was not autostarting through dbus. The notification service was provided by multiple applications and dbus could not decide which to start? I am not sure, but when I uninstalled KDE, the problem was solved for me, and the notifications started to work.

Simple test: notify-send 'test'

If it hangs, then you have a problem.

I am new to wiki editing, this is why I mention this problem here. Maybe it is worth to include this information in the wiki.

—This unsigned comment is by Strseu (talk) 16:34, 14 April 2020‎. Please sign your posts with ~~~~!

If a provider isn't running already, then dbus-daemon basically tries to start whichever first provider it finds at random. If it happens to pick a provider that's completely incompatible with your DE (like maybe if it crashes when Plasma isn't running) then yes, you get timeouts and other errors.
The notification service ought to be exec'd by your DE or WM's startup scripts. D-Bus does not officially support the same bus name being autostartable through multiple providers (and notification daemons shouldn't bother including a D-Bus .service file in the first place). It's actually forbidden for the system bus, and the dbus-daemon maintainer has talked about disabling this behavior also for the session bus.
--grawity (talk) 13:28, 15 April 2020 (UTC)Reply[reply]
I got bit by this with XFCE after installing just KDE systemsettings. It drove me nuts for days - initially I thought it was a bug in XFCE, only then I noticed Thunderbird was also hanging when I refreshed new messages. I added the | Troubleshooting section and it should be here forever.
Danuker (talk) 20:40, 30 June 2020 (UTC)Reply[reply]