You are not logged in.
I just want to say that I love this little gem! I have been using xfce4-notifyd for quite some time now, and it does not always play very nicely with tiling window managers. As an i3 user (and sometimes I use dwm) it looks very native to these interfaces. Thanks for the great work!
Offline
Mogger wrote:1. [Request] A -dock option (like dzen) would be nice, I filed an issue here: https://github.com/knopwob/dunst/issues/68
I'll look into it this weekend.
Thanks!
Mogger wrote:4. In the rules section, I set some notifications to be marked as critical. I expected those to have timeout = 0 (as specified in [urgency_critical]), but it seems like they get the normal timeout = 10. Is that intended or should I file an issue?
It should work as you expect it. Does the rule match at all? Are for example the colors for urgent notifications applied to that notification? Posting your dunstrc might help as well.
Yes the colors are correct. Here's my dunstrc:
[global]
font = Terminus-6
format = "[%s] %b"
sort = yes
indicate_hidden = yes
alignment = center
bounce_freq = 0
show_age_threshold = 60;
word_wrap = yes
geometry = "x3-0+0"
transparency = 0
idle_threshold = 120
monitor = 2
follow = keyboard
sticky_history = yes
line_height = 20
separator_height = 0;
separator_color = foreground
[shortcuts]
close = ctrl+shift+space
close_all = ctrl+mod2+space
history = ctrl+mod2+n
[urgency_low]
background = "#292929"
foreground = "#b3b3b3"
timeout = 10
[urgency_normal]
background = "#292929"
foreground = "#ffffff"
timeout = 10
[urgency_critical]
background = "#ffaaaa"
foreground = "#000000"
timeout = 0
[irssi]
appname = kdialog
summary = "irssi"
urgency = critical
Mogger wrote:5. [Request] What do you think about the possibility to set a custom separator color instead of just "foreground" and "auto"?
I thought about it, but the setting would have to be added to every point where you can change colors. E.g. to every urgency tupe and to the rules. I was just too lazy to implement this and hoped that nobody would want that feature
Maybe I'll do this this weekend... maybe...
Ah, I didn't think that far. For me this is very low priority, if it makes things complicated I would probably prefer to keep it simple rather than have this feature. Support for icons on the other hand... (Yeah I've already seen the previous post about this.)
I'll look into the keybindings problem and report back, hopefully this weekend.
Offline
knopwob wrote:Mogger wrote:4. In the rules section, I set some notifications to be marked as critical. I expected those to have timeout = 0 (as specified in [urgency_critical]), but it seems like they get the normal timeout = 10. Is that intended or should I file an issue?
It should work as you expect it. Does the rule match at all? Are for example the colors for urgent notifications applied to that notification? Posting your dunstrc might help as well.
Yes the colors are correct. Here's my dunstrc:
...snip...
I see nothing wrong with your config. But I think I know what's happening. I guess kdialog is setting a timeout on the notifications (like notify-send -t 5000 foobar). If the client sets a timeout, that timeout won't be overwritten by the urgency settings (the timeouts in the urgency settings are only defaults in the case that the client doesn't set a timeout (and most clients don't)). In this case you have to explicitly set the timeout within the rule itself.
Mogger wrote:5. [Request] What do you think about the possibility to set a custom separator color instead of just "foreground" and "auto"?
knopwob wrote:I thought about it, but the setting would have to be added to every point where you can change colors. E.g. to every urgency tupe and to the rules. I was just too lazy to implement this and hoped that nobody would want that feature
Maybe I'll do this this weekend... maybe...Ah, I didn't think that far. For me this is very low priority, if it makes things complicated I would probably prefer to keep it simple rather than have this feature.
Yeah, I can continue being lazy
Support for icons on the other hand... (Yeah I've already seen the previous post about this.)
Offline
I see nothing wrong with your config. But I think I know what's happening. I guess kdialog is setting a timeout on the notifications (like notify-send -t 5000 foobar). If the client sets a timeout, that timeout won't be overwritten by the urgency settings (the timeouts in the urgency settings are only defaults in the case that the client doesn't set a timeout (and most clients don't)). In this case you have to explicitly set the timeout within the rule itself.
Oooh, that's true, never thought about it but yes, I do set a timeout when calling kdialog (10 s, which confusingly is the same as my urgency_normal timeout). I tried setting timeout = 0 in the rule before and it works fine.
So no bug here, you can sleep soundly tonight!
Offline
I like it, the notifications are far less intrusive than popups. What about a hotkey to open a horizontal menu with the actions defined for a notification, maybe with a little arrow to indicate available actions in front of the message text?
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I like it, the notifications are far less intrusive than popups. What about a hotkey to open a horizontal menu with the actions defined for a notification, maybe with a little arrow to indicate available actions in front of the message text?
I actually never thought about handling actions this way. I always thought about creating extra clickable areas for them but your idea sounds much more easy to implement. Another idea would be to just use dmenu of those. There might even be more potential when using dmenu. I'm currently thinking about a keybinding to open dmenu, which would
a) list all available actions
b) list all urls and open selected url in browser
c) list all apnames and focus selected app
Any thoughts on this?
Offline
dmenu is a good idea, you don't have to reimplement what already exists.
Could you also allow to ignore numlock for the hotkeys (register the hotkeys with and without numlock). I don't always remember to disable it after using the numblock.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Could you also allow to ignore numlock for the hotkeys (register the hotkeys with and without numlock). I don't always remember to disable it after using the numblock.
A-ha, that was the problem here - I had to include mod2 in the keybindings to make them work. I like how xbindkeys handles it - unless you specify mod2, it doesn't matter if numlock is on or not.
I also noticed that dunst segfaults if you set height to 1 (geometry = "x1-0+0") and then display two different messages (notify-send "hello"; notify-send "bye").
Last edited by Mogger (2012-10-06 09:36:20)
Offline
I really like dmenu idea. It would be nice to show history with time stamps.
On light branch it was possible to define fallback font, but this can't be sice xft support was introduced. I fallback font set to stlarch icon font
and I think it is enough for most of the users (who aren't using huge fonts) as far as the icon support goes.
eg. envelope icon for mail, note for new song, msn logo for messenger, thermometer for temperature warnings...
And it looks nice, too.
Offline
I think I have found some odd behaviour with one line geometry.
I haven't updated dunst for some time, so I decided to do fresh compile of aur package and adapt config to new options and changes.The problem:
a) If I send 10 notifications with same text one after another, there is no hidden indicator until I close one notification (I think this is intended, but it makes no sense neither in one line mode or standard geometry).
The next one (same text) shows hidden count, but it shows only 6 hidden, instead of 8.
c) I send 10 different notifications (numbers 1 through 10), and only first one is shown, and after closing it other 9 notifications never show up.
d) Sometiimes sending notification just closes one that is already shown .
e) History only shows the last one - it doesn't cycle.
The width for the window was calculated before the "(x more)" string was appended to the message. So the text was there, the window just wasn't big enough to show it.
This + the segmentation faults when geometry height == 1 where hopefully the cause for these problems. Both should be fixed in the git repository.
And I guess you just didn't noticed the segmentation faults because dbus starts dunst when no notification daemon is running.
Offline
That was quick, thanks!
It doesn't segfault (which I didn't notice before) anymore and all of the issues are gone, but there still one little thing.
If I send 10 same notifications, first it shows notification (1 more), and after closing that one it shows (8) notification.
It seems that it doesn't realise that first and second notification are same. It should show (9) notification.
EDIT: It would also be nice to show newest notification first, if they all have same urgency level. This somehow makes more sense to me.
And what line height actually does? I can't see any difference between values of 0 and for example 13 (my font height)?
Last edited by Šaran (2012-10-07 14:25:02)
Offline
If I send 10 same notifications, first it shows notification (1 more), and after closing that one it shows (8) notification.
It seems that it doesn't realise that first and second notification are same. It should show (9) notification.
I can't reproduce the first part. If I send two identical messages I get "(1) foobar" which is the intended behaviour. The displayed number shows the amount of additional copies of the notification. So it doesn't count the original message.
It would also be nice to show newest notification first, if they all have same urgency level. This somehow makes more sense to me.
I have to see whether I can make the sorting order configurable.
And what line height actually does? I can't see any difference between values of 0 and for example 13 (my font height)?
Between 0 and font_height this option does absolutly nothing If it's bigger than the font height it adds additional padding space below and above the text to increase the window size without increasing the font size.
If you're using config.h to configure dunst, you might still want to take a look into the default dunstrc, because the options there have additional comments
Offline
I have some notifications with a progressbar and I'd like to see the percentage after message, so I patched my build to add a %p variable. If you like to add it, here is the patch.
Edit: Created a pull request on github here.
Edit: I really have to find my github password again... Here are two bug reports:
1) In init_notification, you forgot to set the ID when a notifications is replaced.
2) When you check for duplicate messages, you should check the appname, too I think.
Last edited by progandy (2012-10-07 20:23:40)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I can't reproduce the first part. If I send two identical messages I get "(1) foobar" which is the intended behaviour. The displayed number shows the amount of additional copies of the notification. So it doesn't count the original message.
On two identical, I get "foobar (1 more)".
Between 0 and font_height this option does absolutly nothing If it's bigger than the font height it adds additional padding space below and above the text to increase the window size without increasing the font size.
If you're using config.h to configure dunst, you might still want to take a look into the default dunstrc, because the options there have additional comments
Oh, I see. In that case I have a sugestion.
Line height does increase window size, but it doesn't properly align text.
On the right is date displayed by LemonBar (same font as dunst - "-*-ohsnap-medium-*-*-*-13-*-*-*-*-*-*-*", height of 15 pixels). Next to it is dunst displaying same text with line height 15.
As you can see, dunst positions text much lower than bar, same way as dmenu does. And dices on the left clearly show that bar handles alignment properly.
On height 20, text gets aligned like it should, but on height 13 (enough for the font to get displayed), this happens:
EDIT:
On light branch it was possible to define fallback font, but this can't be sice xft support was introduced. I fallback font set to stlarch icon font
and I think it is enough for most of the users (who aren't using huge fonts) as far as the icon support goes.
eg. envelope icon for mail, note for new song, msn logo for messenger, thermometer for temperature warnings...
And it looks nice, too.
I have just built dunst configured with confg.h and it turns out this is still possible! Nice.
char *font = "-*-ohsnap-medium-*-*-*-13-*-*-*-*-*-*-*,-*-stlarch-*-*-*-*-10-*-*-*-*-*-*-*";
Last edited by Šaran (2012-10-07 19:02:31)
Offline
OK, so another "nice-to-have" that I wonder whether it's feasible to implement: I really like the idle_threshold feature, but one thing that makes it less usable is that the notifications disappear after <timeout> when I become active again. The main problem is that I have to use the mouse/keyboard to wake up the monitors from power save mode. This gives me very little time to check the notifications before they disappear, and then I have to bring every one up again from history (with no information about how old they were).
On the other hand, it would be annoying to come back to dozens of notifications about files that have changed in Dropbox, new RSS feed updates, people that have signed on and off, etc.
So my first thought was to introduce a new timeout option, then I could set idle_timeout to 0 for [urgency_normal] and idle_timeout = 10 for [urgency_low], for example. A simpler way would perhaps be to add the possibility to match messages by their idle status. In that case I could just make a rule for the notifications that I want to stay, e.g.
[irssi]
appname = kdialog
summary = "irssi"
idle = yes
timeout = 0
A third alternative is to make all "idled" notifications stay and add idle_threshold to the urgency sections:
[urgency_low]
timeout = 0
idle_threshold = 0
[ungency_normal]
timeout = 10
idle_threshold = 120
Thoughts on that?
Offline
well im liking this. does the job, dont really need anything fancier
i coded a new feature for myself where you can do notify with a "command" hint and when you middle-click that notification it runs the command. not sure if anyone else would find it useful, i figured id keep it to myself, since publicly it seems it could easily be exploited by other programs. tho you do have to middle-click to execute, so i dunno. and im not a pro coder or anything, so its probably done wrong anyways
now im just trying to configure it right... some of the config settings a lil confusing, but i think i almost have it how i want
ok well the major annoying thing im noticing right now is with bounce. would be nice to have a set speed instead of a frequency. text gets too long and it keeps going faster, cant read it.
Last edited by Dan39 (2012-10-08 03:30:11)
Offline
I discovered dunst recently! Very very nice! I also use it to show reminders via
remind '-knotify-send %s' ~/.reminders
The remind command just places the message of the reminder in %s and executes the command. It works pretty fine except from the fact that I would like to specify some sort of urgency via colors. Is that possible. Perhaps some markup language.
Offline
Did I miss an option to set the inner padding of the notifications? I would like to add some more space around the text (while not increasing the line height).
Otherwise I really like it!
Offline
I've got a very minor UI question - Today I tried out setting the geometry width variable to 0, so dunst would only be as long as the message it contains. But now, my notifications all appear at the left-side of my screen! Is there a way to centre the dunst bar while still keeping its width down to a minimum?
"Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying "End-of-the-World Switch. PLEASE DO NOT TOUCH", the paint wouldn't even have time to dry."
Offline
progandy wrote:I like it, the notifications are far less intrusive than popups. What about a hotkey to open a horizontal menu with the actions defined for a notification, maybe with a little arrow to indicate available actions in front of the message text?
I actually never thought about handling actions this way. I always thought about creating extra clickable areas for them but your idea sounds much more easy to implement. Another idea would be to just use dmenu of those. There might even be more potential when using dmenu. I'm currently thinking about a keybinding to open dmenu, which would
a) list all available actions
b) list all urls and open selected url in browser
c) list all apnames and focus selected appAny thoughts on this?
a) yes please.
b) yes please.
c) yes please.
d) more of that potential.
i utterly love dunst
(though i've only tried it in #! waldorf from the wheezy repo, and get dbus errors when trying to run without root privs, same connection fail errors hellomynameisphil was getting earlier in the thread, though no one seemed to have an answer for him either)
it's development rate is pleasingly quick. i hope it stays nimble and small through this feature boom. though i cant see it ever getting as bad as the competition.
tickr, dmenu, tint2, xmobar/i3status/scrotwm's-bar/etc, and now dunst. i like these sorts of neat clean configurable things. very glad dunst was created and i managed to come across it. ... now if i can only get it to reliably work in a useful way (not as root).
fave quote of the mo': "Man's reach should exceed his grasp, else what's a heaven for." - Robert Browning
Offline
Expanding with dmenu would be niceeeee
Last edited by Unia (2012-11-23 22:40:04)
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
I have been using dunst for a while now, but I there has been one thing bothering me lately. When xscreensaver locks my screen any notification sent is displayed with dunst over top of xscreensaver. Is this the correct behavior? If so, is there any way to change this? I prefer not having any information about my computer showing up when my screen is locked. Thanks.
Offline
I have been using dunst for a while now, but I there has been one thing bothering me lately. When xscreensaver locks my screen any notification sent is displayed with dunst over top of xscreensaver. Is this the correct behavior? If so, is there any way to change this? I prefer not having any information about my computer showing up when my screen is locked. Thanks.
After spending an evening trying to find an error in code that wasn't actually wrong and a visit to the xorg irc channel there doesn't seem to be a universal way to detect a running screensaver.
The same can be said about screen locking tools (slock, i3-lock etc.).
The only thing I can reliably detect is idle time (no user input). So a workaround might be an option to stop displaying notifications and keep them in the queue if the user is idle for x amounts of minutes. So you could set this idle time to the time you have configured in your screensaver. But this solution doesn't feel right so I have to think about it some more to see wether I can come up with another solution for this problem.
Offline
I have problems with printing newlines in dunst.
When I run this from zsh:
notify-send "a\nb" "c\nd"
I get:
a
b
c d
When I run this from Python:
subprocess.call('notify-send "a\nb" "c\nd"', shell=True)
I get this:
a b
c d
I both cases I expected this:
a\nb
c
d
Or this:
a\nb
c
d
Or at least this:
a
b
c
d
When I stop dunst and show the same notification with the Gnome notification daemon, the result is this which seems fine:
a\nb
c
d
I think it would make sense to respect newlines in the body part of notifications while it seems optional (or unnecessary?) to have them in the summary.
Offline