dunst - a dmenu-ish notification daemon

r4 · 2013-05-27 16:56:18

Glad to hear I'm not the only one noticing this.

raining · 2013-05-28 14:57:13

progandy wrote:

ninian wrote:
r4 wrote:
For some reason dunst doesn't seem to respect my timeouts consistently.
Hmm... I'm using 10 second timeouts for urgency low and normal and I could swear sometimes the message persists for about 3 x longer.
Haven't pinned it down consistently though.
I have seen it too. messages stay too long, until a new one pops up or sometimes forever. If I use the history function, the window doesn't update properly either. I cannot find the reason, though.

I am facing the same inconsistency as well. Sometime everthing piles up untill i click on it to make it disappear.

btw. Thanks You, knopwob for making such an awesome program.

onebitaway · 2013-06-04 20:11:00

Observing strange behavior with timeouts here.
Most of the time notifications stay until manually closed, although sometimes they expire as expected.
Using notify-send and tested dunstify from the git repository.

notify-send -t 5 title message
dunstify -t 5 title message

both with the same result.

progandy · 2013-06-10 16:36:17

I may have a fix ready. https://github.com/progandy/dunst/

firecat53 · 2013-06-10 18:18:48

Hey, I don't know if this is a dunst quirk, or something with the lightweight screen lockers, but if a notification is received with either i3lock or sflock (only 2 I've used) engaged, then you can see a unreadable wavy/discolored area on top of the lock screen where the notifications would normally sit. I think I would expect to see nothing at all. If you need more info, let me know.

Thanks!
Scott

zeltak · 2013-07-07 18:32:10

Hi all

i decided finally after a few months of dust to further config dunst but running into an issue with the specific color optione per app

i have something like this:

[sxhkd]
appname = sxhkd
timeout = 0
background = "#000000"
foreground = "#dddddd"

i know its wrong in syntax since its not really working, how does one specift per app colors, is it based on wm_class, instance etc?

thx alot

Z

knopwob · 2013-07-08 11:51:34

zeltak wrote:

Hi all
i decided finally after a few months of dust to further config dunst but running into an issue with the specific color optione per app
i have something like this:
[sxhkd]
appname = sxhkd
timeout = 0
background = "#000000"
foreground = "#dddddd"
i know its wrong in syntax since its not really working, how does one specift per app colors, is it based on wm_class, instance etc?
thx alot
Z

You can run dunst -verbose in a terminal to see what the programs are sending as their appname.

zeltak · 2013-07-08 21:20:05

Hya

thx for the answer!

the problem i guess is that all apps give the same appname, IE

appname: 'notify-send'
summary: 'interrobang'
body: ''
icon: ''
urgency: 1
formatted: 'interrobang'
fg: #FDBE6A
bg: #000000
id: 76
script: (null)

can i use the summary to create the per app colors, am i missing something, arent all app names going to be notify-send?

thx again

Z

Last edited by zeltak (2013-07-08 21:20:53)

progandy · 2013-07-08 22:37:58

can i use the summary to create the per app colors, am i missing something, arent all app names going to be notify-send?

The appname should be uniqe to the application creating the notification. That's why it is called appname. notify-send lets you define the appname manually since it is designed to be used in different scripts.
As for the rule matching I quote the example dunstrc

# Messages can be matched by 'appname', 'summary', 'body' or 'icon'
# and you can override the 'timeout', 'urgency', 'foreground', 'background'
# and 'format'.
# Shell-like globbing will get expanded.

Last edited by progandy (2013-07-08 22:43:18)

madalu · 2013-07-11 23:26:54

Great tool! Might I request a configuration option to turn off the context menu and url detection? The URL regexp detection picks up mailto addresses, but does so inconsistently. For instance "some.address@gmail.com" becomes "gmail.com" in the context menu. Since my primary use for notify-send is to broadcast new emails, I would prefer not to see the "(U)" at the start of every notification.

Last edited by madalu (2013-07-11 23:28:37)

manuelschneid3r · 2013-08-09 12:50:30

Pretty cool. thanks! But make an option making dunst capable of overwriting notifications, that are sent from the same app. I would need it for a "Volume Notification" in case of change.

Regards

progandy · 2013-08-09 15:11:03

manuelschneid3r wrote:

Pretty cool. thanks! But make an option making dunst capable of overwriting notifications, that are sent from the same app. I would need it for a "Volume Notification" in case of change.
Regards

dunst supports the complete notification protocol (except some graphical extensions like images)
You can replace a notification if you use the same id, only notify-send does not support it. You'll need to download the dunst source and compile "dunstify" which supports this. On the first call store the notification id in a temp file. on succesive calls reuse it. There is an example called replace in https://github.com/knopwob/dunst/blob/m … st/test.sh

awh · 2013-09-20 22:50:30

firecat53 wrote:

Hey, I don't know if this is a dunst quirk, or something with the lightweight screen lockers, but if a notification is received with either i3lock or sflock (only 2 I've used) engaged, then you can see a unreadable wavy/discolored area on top of the lock screen where the notifications would normally sit. I think I would expect to see nothing at all. If you need more info, let me know.
Thanks!
Scott

Came to this thread to report the same thing.
I assume you SIGUSR1'd dunst before locking your screen like me?
I got a strace (-fv) of dunst when this happens: http://paste.ubuntu.com/6134805/
For me the wavy area is just a big black box.

3xOSC · 2013-12-30 05:54:40

my dunstrc that's living in my ~/.config/dunst/ folder simply isn't being read (checked with strace) but the changes aren't applying, does anyone know why?

EDIT: solved, turns out i needed to restart my computer. weird o_O

Last edited by 3xOSC (2013-12-30 06:04:17)

milomouse · 2014-01-12 15:35:53

May have missed it, but is there a way to stack messages horizontally instead of vertically?

What I mean is... if you get a message notification, it's displayed where you specified it to in the dunst config, but if you receive another message before the previous one times out then it is stacked below the previous one, and these continue to stack vertically (downwards) with each new message in this fashion. I was wondering if you could stack them beside (left/right) each other in a line of sorts.. instead of a column below/above each other.

If this functionality exists I apologize as I must have missed it. If not, then what do you think about it?

milomouse · 2014-01-12 15:37:45

3xOSC wrote:

my dunstrc that's living in my ~/.config/dunst/ folder simply isn't being read (checked with strace) but the changes aren't applying, does anyone know why?
EDIT: solved, turns out i needed to restart my computer. weird o_O

If dunst was already running before you made changes in the config, I think you need to kill it before your new config changes are recognized, I believe?

faiden · 2014-04-20 18:38:28

If you're piping the logs from journald into dunst via a script and if you have some ignore entries in dunstrc then dunst will be stuck in an endless loop telling you what notification it has skipped.

Is there an option to turn off logging what dunst is skipping? If not, could an option for this be added?

hobarrera · 2014-06-26 10:27:30

I've a very odd issue with dunst.
I've two computers, a laptop and a desktop, both with i3 and identical configurations, and all the latest packages from the official repos.

On my laptop, alt+space dismisses the notifications, on the desktop, it does not (nothing happens). stdour/stderr show nothing, and I've no idea what to try. What can be causing this issue? What should I look at? My configuration is available here

hobarrera · 2014-07-16 20:03:07

Is there any chance of getting rounded borders? Or would that be a paint to implement?
I'd also sort-of like double frame: Grey notification bg, a white frame, and a black 1px frame outside that. Is that possible, or am I getting too picky?

Thanks!

dejy · 2014-09-11 16:17:58

Is there a way to make Notifications go to the same box (Override the previous notify box), as opposed to spawning it's own new Notify event?

For example running a bash-script for notifying on Caps-lock state the following problem occurs (if one changes Capslock several times before the time out intervals)

#*press capslock 
    < Capslock ON>
#*press capslock 
   < Capslock ON>
   < Capslock OFF>
#*press capslock 
   <(1) Capslock ON>
    < Capslock OFF>
#*press capslock 
  <(1) Capslock ON>
 <(1) Capslock OFF>

So generally it will like this: 
<(1) Capslock ON>
<(1) Capslock OFF>

Which is not priority sorted and completely ambiguous. (And there are a number of notification events for which this would not make sense).
One alternative is to use a Python script and Notification.close(), but it also seems awkward to run a .py script and import subprocess / evdev libraries just for two lines of bash script.

Anyways if there is a way to notify-send into a single-box, or other effective work arounds, that would be great to know.

Last edited by dejy (2014-09-11 17:37:51)

hobarrera · 2014-09-11 16:41:11

dejy wrote:

Is there a way to make Notifications go to the same box (Override the previous notify box), as opposed to spawning it's own new Notify event?
For example running a bash-script for notifying on Caps-lock state the following problem occurs (if one changes Capslock several times before the time out intervals)
#*press capslock 
    < Capslock ON>
#*press capslock 
    < Capslock OFF>
#*press capslock 
 <(1) Capslock ON>
#*press capslock 
 <(1) Capslock OFF>

So generally it will like this: 
<(1) Capslock ON>
<(1) Capslock OFF>
Which is not priority sorted and completely ambiguous. (And there are a number of notification events for which this would not make sense).
One alternative is to use a Python script and Notification.close(), but it also seems awkward to run a .py script and import subprocess / evdev libraries just for two lines of bash script.
Anyways if there is a way to notify-send into a single-box, or other effective work arounds, that would be great to know.

Rather than a mere script, I'd have a tiny daemon that updates the same notification, and signal that daemon.

dejy · 2014-09-11 17:17:00

hobarrera wrote:

dejy wrote:
Is there a way to make Notifications go to the same box (Override the previous notify box), as opposed to spawning it's own new Notify event?
For example running a bash-script for notifying on Caps-lock state the following problem occurs (if one changes Capslock several times before the time out intervals)
#*press capslock 
    < Capslock ON>
#*press capslock 
    < Capslock OFF>
#*press capslock 
 <(1) Capslock ON>
#*press capslock 
 <(1) Capslock OFF>

So generally it will like this: 
<(1) Capslock ON>
<(1) Capslock OFF>
Which is not priority sorted and completely ambiguous. (And there are a number of notification events for which this would not make sense).
One alternative is to use a Python script and Notification.close(), but it also seems awkward to run a .py script and import subprocess / evdev libraries just for two lines of bash script.
Anyways if there is a way to notify-send into a single-box, or other effective work arounds, that would be great to know.
Rather than a mere script, I'd have a tiny daemon that updates the same notification, and signal that daemon.

So what you mean (correct me if i'm wrong) is something like having a little python daemon receiving socketIO events on keypress - and updating the notifications from there?

And I take it that's a no, on updating a new message to the same notification window (maybe forking dunst, to enable something like this would be preferable?)

progandy · 2014-09-11 17:37:07

If you use dunstify instead of notify-send, you can store and set the notification id in order to replace a message. dunstify is part of the dunst sources, but not included in the arch package.

wget https://raw.githubusercontent.com/knopwob/dunst/master/Makefile
wget https://raw.githubusercontent.com/knopwob/dunst/master/dunstify.c
touch config.mk
make dunstify

dunstify -p ... >nid
dunstify -r $(<nid) ...

Last edited by progandy (2014-09-11 17:40:17)

dejy · 2014-09-11 17:45:33

progandy wrote:

If you use dunstify instead of notify-send, you can store and set the notification id in order to replace a message. dunstify is part of the dunst sources, but not included in the arch package.
wget https://raw.githubusercontent.com/knopwob/dunst/master/Makefile
wget https://raw.githubusercontent.com/knopwob/dunst/master/dunstify.c
touch config.mk
make dunstify

dunstify -p ... >nid
dunstify -r $(<nid) ...

+1, exactly what I needed.

ngoonee · 2015-05-18 08:29:03

knopwob wrote:

progandy wrote:
knopwob wrote:
exactly. an A would indicate an Action btw. and the url detection gets a lot of false positives. But I prefer this to wrongly not detected urls. patches that improve url detection are welcome. see menu.c
I added a commit to my fork, feel free to cherry-pick this and any other commit I made
https://github.com/progandy/dunst/commi … 78ee1a0288
I've picked most of your commits (not yet pushed to my github) except for the two icon related commits. I've not yet decided wether I want to merge those, since I'm thinking about adding real icon support. Anyway thank you for your efforts.

Any update on the icon support?

Edit: ignore me please, trigger-happy posting.

Last edited by ngoonee (2015-05-18 09:22:49)

Arch Linux

#351 2013-05-27 16:56:18

Re: dunst - a dmenu-ish notification daemon

#352 2013-05-28 14:57:13

Re: dunst - a dmenu-ish notification daemon

#353 2013-06-04 20:11:00

Re: dunst - a dmenu-ish notification daemon

#354 2013-06-10 16:36:17

Re: dunst - a dmenu-ish notification daemon

#355 2013-06-10 18:18:48

Re: dunst - a dmenu-ish notification daemon

#356 2013-07-07 18:32:10

Re: dunst - a dmenu-ish notification daemon

#357 2013-07-08 11:51:34

Re: dunst - a dmenu-ish notification daemon

#358 2013-07-08 21:20:05

Re: dunst - a dmenu-ish notification daemon

#359 2013-07-08 22:37:58

Re: dunst - a dmenu-ish notification daemon

#360 2013-07-11 23:26:54

Re: dunst - a dmenu-ish notification daemon

#361 2013-08-09 12:50:30

Re: dunst - a dmenu-ish notification daemon

#362 2013-08-09 15:11:03

Re: dunst - a dmenu-ish notification daemon

#363 2013-09-20 22:50:30

Re: dunst - a dmenu-ish notification daemon

#364 2013-12-30 05:54:40

Re: dunst - a dmenu-ish notification daemon

#365 2014-01-12 15:35:53

Re: dunst - a dmenu-ish notification daemon

#366 2014-01-12 15:37:45

Re: dunst - a dmenu-ish notification daemon

#367 2014-04-20 18:38:28

Re: dunst - a dmenu-ish notification daemon

#368 2014-06-26 10:27:30

Re: dunst - a dmenu-ish notification daemon

#369 2014-07-16 20:03:07

Re: dunst - a dmenu-ish notification daemon

#370 2014-09-11 16:17:58

Re: dunst - a dmenu-ish notification daemon

#371 2014-09-11 16:41:11

Re: dunst - a dmenu-ish notification daemon

#372 2014-09-11 17:17:00

Re: dunst - a dmenu-ish notification daemon

#373 2014-09-11 17:37:07

Re: dunst - a dmenu-ish notification daemon

#374 2014-09-11 17:45:33

Re: dunst - a dmenu-ish notification daemon

#375 2015-05-18 08:29:03

Re: dunst - a dmenu-ish notification daemon

Board footer