New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to disable dunst in Unity #363

Closed
Maxlufs opened this Issue Aug 24, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@Maxlufs

Maxlufs commented Aug 24, 2017

How can I disable dunst as the default notification daemon in Unity?

After installing i3wm and switched back to dunst, dunst is taking charge over notify osd. The solution online was to purge dunst at all. Is there any other configuration that I could use dunst in i3 while keep notify osd in Unity?

Thanks!

@tsipinakis

This comment has been minimized.

Member

tsipinakis commented Aug 27, 2017

Sorry for the delay, as mentioned in another comment I wasn't home for the past few days.

Dunst (and probably notify-osd) are started automatically via a dbus service usually located in /usr/share/dbus-1/services/ (dunsts service for example is org.knopbox.dunst.service).

if you remove these files the notification daemon will not be started automatically when a notification comes through meaning that you'll have to start it yourself at every session (and restart when it crashes).

@tsipinakis

This comment has been minimized.

Member

tsipinakis commented Sep 8, 2017

@Maxlufs Was your question resolved? If so you should close the issue.

@bebehei

This comment has been minimized.

Member

bebehei commented Sep 8, 2017

@tsipinakis This is a common problem and IMHO the solution "remove the file manually from /usr" is not a good solution. It's against every principle of Unix. But I can't say that solution is wrong, it's currently the best.

If you close this issue, there should be at least a FAQ/wiki entry about a good the solution. Others will have this problem later, too. In other projects I had a similar type of issue, opened a bugreport, but it got closed again as a duplicate of another bug. This is contraproductive. The maintainer is pissed, I've created work and others will also tap into this trap. We should have a note somewhere at least.

I did some research today about conflicting DBUS Busses, but I could not find anything. I will join the dbus IRC this evening and search ask those guys. Maybe someone of the pros has better understanding.

@WhyNotHugo

This comment has been minimized.

Contributor

WhyNotHugo commented Sep 8, 2017

This is a common problem and IMHO the solution "remove the file manually from /usr" is not a good solution.

Well, you want to install an application, but avoid other applications from discovering it, I don't think there's a really clean solution.

As an alternative though; if you manually start notify-osd, does dunst still get auto-started when sending a notification?

@tsipinakis

This comment has been minimized.

Member

tsipinakis commented Sep 8, 2017

This is a common problem and IMHO the solution "remove the file manually from /usr" is not a good solution.

As you said, while I also don't like the solution there is no workaround currently and it's not an issue dunst can fix - this is up to dbus.

As an alternative though; if you manually start notify-osd, does dunst still get auto-started when sending a notification?

I'd assume no here since there's already an application on that address so dbus doesn't attempt the activation of another one. The real question is how dbus decides which one to launch if both use the same address.

@bebehei

This comment has been minimized.

Member

bebehei commented Sep 10, 2017

Finally:

There is no clean possibility to have different notification-managers on a per-session basis. To switch automatically per session, you would have to write an (easy) script, which starts based on its env (or the surrounding processes) the notification-daemon manually.

But, there is a quite easy solution on a per user basis. This is simply everything to do:

# use dunst
SERVICE=org.knobwob.dunst
# use default
SERVICE=
mkdir -p "${XDG_DATA_HOME:-~/.local/share}/dbus-1/services"
ln -sT \
    "/usr/share/dbus-1/services/${SERVICE:-org.Freedesktop.Notifications}.service" \
    "${XDG_DATA_HOME:~/.local/share}/dbus-1/services/org.freedesktop.Notifications.service"

It looks quite complex, but it actually just links the service-file into the user's home-directory, where dbus uses these files with higher precedence. Depending on the content of the SERVICE variable, it either uses the default or dunst (or any other configuration, you put in there.

I think we should document this somewhere in the FAQ/somewhere else. If I figure out, how the dunst-project.org repo is organized, I'll fire a PR against it. Edit: mhmmm. There is no FAQ on the website!?


The real question is how dbus decides which one to launch if both use the same address.

  • There is standard_session_servicedirs, which is a PATH option, containing multiple folders, searched for .service-files. If two files containing the same Name=ghi.def.abc, then the file in the first directory will be taken. As the PATH-option is structured $XDG_DATA_HOME/dbus-1/services:[...]:${datadir}/dbus-1/services[0], you can always overwrite as a user the default services in your home.
  • If two files containing the same Name=ghi.def.abc are in the same directory, the selection is arbitary. So non-deterministic. Even if one of the files is called ghi.def.abc.service, there is no real precedence.

So there is at least a solution, which does not touch /usr and does this also on a per-user-basis.

[0] XDG_DATA_HOME defaults to ~/.local/share and datadir to /usr/share/

@WhyNotHugo

This comment has been minimized.

Contributor

WhyNotHugo commented Sep 12, 2017

@bebehei Thanks for that thorough explanation.

@tsipinakis

This comment has been minimized.

Member

tsipinakis commented Sep 12, 2017

I think we should document this somewhere in the FAQ/somewhere else. If I figure out, how the dunst-project.org repo is organized, I'll fire a PR against it. Edit: mhmmm. There is no FAQ on the website!?

I've been meaning to do some work on the website for a while now, especially adding some more documentation on there, but it'll have to wait until I get some more free time. In the meantime feel free to send a PR if you want to work on this, otherwise there's a FAQ on the github wiki free for everyone to edit.

@bebehei

This comment has been minimized.

Member

bebehei commented Sep 12, 2017

So, I ported the FAQ-stuff to the website and added the explanation to this issue: Fixed in dunst-project/dunst-project.org#2

@bebehei

This comment has been minimized.

Member

bebehei commented Sep 18, 2017

@tsipinakis after dunst-project/dunst-project.org#2 got merged, what about closing this here?

@tsipinakis tsipinakis closed this Sep 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment