Open bobkron opened 5 months ago
I would say that killall dunst suffices, since the notification daemon is started automatically whenever a notification is sent
Actually yes, that would suffice...will make the changes right away.
Wouldn't it be enough to just describe what to do? There may be systems where killall
is not available. And as there are a lot of different programs around for such a task (kill
, killall
, pkill
, ...) it could be benefical to just explain in general what to do.
Wouldn't it be enough to just describe what to do? There may be systems where
killall
is not available. And as there are a lot of different programs around for such a task (kill
,killall
,pkill
, ...) it could be benefical to just explain in general what to do.
you have a point. maybe just saying if you kill dunst (eg killall dunst) it will be started automatically when a notification is sent
is enough?
Just my 2 cents here ...
since the notification daemon is started automatically whenever a notification is sent
This is correct, but dunst
might not be the only notification daemon installed and without (re)starting it explicitly there's no guarantee that dunst
is started on the next notification sent (it could be another daemon).
To add some other approach (the one I'm using), which relies on systemd user services and path triggers:
Since dunst does not have a reload feature, added instructions in the docs to reload
.dunstrc
after making changes, without needing to restart the window manager every time a change is made during configuration.