Dunst: signal to reload dunstrc

Created on 14 Sep 2012  路  15Comments  路  Source: dunst-project/dunst

Most helpful comment

My workaround is to killall dunst;notify-send foo. Works fine on debian.

All 15 comments

won't implement

that would have been very handy :/

My workaround is to killall dunst;notify-send foo. Works fine on debian.

@knopwob: why not? Is something blocking this?

@knopwob: why not? Is something blocking this?

because the workaround posted above works good enough, IMHO.

@Eizen @tsipinakis your opinions? Feel free to reopen this issue, if you think otherwise.

A workaround has already been mentioned and I don't think reloading the configuration is something that needs to be done that often, so I'm not sure how useful implementing this will be.

That being said, I'd reopen this if there is a use-case that I haven't considered. @piahoo can you elaborate on why you need this feature?

How exactly does that work around work? That highly depends on how you're starting dunst. I for one do it with a simple: exec --no-startup-id dunst on my i3 config. With doesn't get executed when restarting i3 in place or reloading i3.
That makes reloading the dunst config quite annoying.
@tsipinakis

@luan From i3's documentation:
"if you need a command to run also when restarting i3 you should use the exec_always keyword"

You could easily use: exec_always --no-startup-id dunst as a workaround. Besides for any other use-case one could use a keybind with the previous workaround, in i3 for example: bindsym $mod+Shift+d --release exec --no-startup-id killall dunst;notify-send foo. So i don't really see a valid reason to implement this so far.

As @Eizen said. It's also expected that you're using the dbus service so that dunst starts automatically when a notification is sent. Is there any reason you're starting dunst manually @luan ?

As a workaround for now I am using sudo pkill dunst and then dunst -config ~/.config/dunst/dunstrc &

Edit (@bebehei): Please do not start dunst manually after killing it. DBus does a great service there and automatically restarts the programs. Use the "official workaround": killall dunst;notify-send foo

@Aeres-u99 It does not do a great service.
killall dunst does not work for me (I don't know what other program is being considered by D-Bus) and the Arch Wiki says:

Note: It may seem like there's no need to manually start dunst, as it may get autostarted by dbus-daemon when programs send notifications through D-Bus. However, the notification service frequently has multiple daemons installed, and there is no way to know which daemon will be autostarted. The dbus-daemon maintainers explicitly warn against relying on autostart for multiple-provider services.

@tsipinakis One reloads dunst every time they change configuration. I think that's often enough.

This could be added with #651 , when that's done.

The main problem here was that there was no way to send commands to dunst outside the normal notification API. With that this issue is resolved.

I don't know what other program is being considered by D-Bus

You can find out with:
grep -r Notifications /usr/share/dbus-1/services/

notify-send while Dunst is not open just hangs indefinitely. dbus does not automatically start dunst for me, even though grep -r Notifications /usr/share/dbus-1/services/ says ./usr/share/dbus-1/services/org.knopwob.dunst.service:Name=org.freedesktop.Notifications.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mrmoroshkin picture mrmoroshkin  路  4Comments

coxley picture coxley  路  4Comments

progandy picture progandy  路  6Comments

existme picture existme  路  4Comments

patrick-motard picture patrick-motard  路  6Comments