dunst - a dmenu-ish notification daemon

knopwob · 2011-09-07 12:47:15

Hello everybody,

The information in this post is very out of date. Have a look at the homepage for a more up to date introduction.

I've spend the last day creating a simple notification-daemon. It uses the drawing code from dmenu and because of that looks a lot like it.
It can listen to notifications from libnotify or be used standalone to display messages (maybe useful in some scripts).
Originally it was suppost to be a patch for dwm and I just used the drawing code from dmenu to prevent constant restarting of dwm to test it.
But in the end i figured it would be more usefull as a standalone application.

homepage

The source is available at http://github.com/knopwob/dunst

If you're interested in this kind of notification-daemon make sure you also check out twmn .

Here are a few screenshots of dunst at work:

critic, suggestions, and so on is welcome, of course.

Last edited by knopwob (2012-08-23 19:18:00)

davidbe · 2011-09-08 20:10:21

This is *exactly* what I was looking for! I'll try it out immediatly!

Army · 2011-09-08 20:56:22

I created a PKGBUILD for those who want to test it.

Just to be sure, I got it right to use libnotify as an optional dependency? Same about the license, it's MIT right? I'm not sure, because you only have a LICENSE.dmenu file. Or does the MIT license say, if you use code which is licensed under MIT, your code has to have the same license? I don't know anything about such things you know I'd chose the WTFPL

Last edited by Army (2011-09-08 20:59:45)

knopwob · 2011-09-08 21:08:38

Army wrote:

I created a PKGBUILD for those who want to test it.
Just to be sure, I got it right to use libnotify as an optional dependency? Same about the license, it's MIT right? I'm not sure, because you only have a LICENSE.dmenu file. Or does the MIT license say, if you use code which is licensed under MIT, your code has to have the same license? I don't know anything about such things you know I'd chose the WTFPL

Yes, libnotify is optional.
I don't know anything about licensing either. I just included the license of dmenu because two source files are taken from that project and I wanted to be on the safe side. I don't know if and how I can mix licenses together for different parts of the sources. For the time being MIT license sounds okay.

Army · 2011-09-08 21:12:27

Is it possible to make it disappear with a keybinding? I'm on a tiling window manager, so I'd prefer to not use the mouse whenever possible.

knopwob · 2011-09-08 21:15:56

Army wrote:

Is it possible to make it disappear with a keybinding? I'm on a tiling window manager, so I'd prefer to not use the mouse whenever possible.

Not at the moment, but I'll try to implement it.

knopwob · 2011-09-08 22:46:26

knopwob wrote:

Army wrote:
Is it possible to make it disappear with a keybinding? I'm on a tiling window manager, so I'd prefer to not use the mouse whenever possible.
Not at the moment, but I'll try to implement it.

If just pushed some changes to add keybindings to close the notifications. With that I've added two new options:

-key $key  --> the key that should close the window. (a,b,space,Return etc.)
-mod $mod --> the modifier used in combination with the key (ctrl,shift,mod1,mod2..mod4)

If you get an error similar to this:

X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  33 (X_GrabKey)
  Serial number of failed request:  67
  Current serial number in output stream:  77

then the key-modifier combination is already taken by something else. For example by the window manager.

chneukirchen · 2011-09-11 23:59:40

Awesome. One thing that would make it perfect is a real -geometry argument so one could specify some distance to the border (e.g. -geometry -5+5)... and perhaps multiline message support?

Army · 2011-09-12 09:13:35

+1 for multiline message support, that would be great!

knopwob · 2011-09-12 11:09:59

chneukirchen wrote:

Awesome. One thing that would make it perfect is a real -geometry argument so one could specify some distance to the border (e.g. -geometry -5+5)... and perhaps multiline message support?

I'll keep those things in mind but I'm pretty busy this week so don't expect anything before the weekend. Anyway, with multiple lines and with the noexpand option, would you prefer each line to have only the length of it's text or all lines to expand to the length of the longest text, e.g a clean box.

Army · 2011-09-12 11:38:08

to the longest text imho, looks better

chneukirchen · 2011-09-12 16:23:48

I would expect a box, but even better would be word-breaking to the given width.

Also, further improvement: pidgin-notify sends HTML entities like >, ' in the dbus text that should be unescaped. (And I think the spec even allows HTMLy stuff like <font color=red>..., I would just skip these.)

knopwob · 2011-09-12 17:16:14

chneukirchen wrote:

I would expect a box, but even better would be word-breaking to the given width.

let me rephrase that to see if I understand you correctly: you want to be able to define a max width of the text box (with the to-be-implemented -geometry option) and a one-line-message that would be longer than the given width will be broken up into a two-line-message? That sounds doable. Maybe the second line should be indented or another visual clue that it is the continuation of the first line.

chneukirchen wrote:

Also, further improvement: pidgin-notify sends HTML entities like >, ' in the dbus text that should be unescaped. (And I think the spec even allows HTMLy stuff like <font color=red>..., I would just skip these.)

I never noticed this before (maybe my brain is trained to skip these things ), but yeah this is an issue that I will address.

But as I stated in the post before: don't expect anything before the weekend. I have a written exame about database programming on thursday which I have to focus on (even though I don't want to )

knopwob · 2011-09-12 23:20:57

okay, i took a break from learning and implemented multiline. With that i removed the -b and -ne options. These things are now done with the -geometry option. Take a look at the manpage for more info about that. If there's anything unclear or need to be rephrased or not working let me know. I've also updated my first post with 2 new screenshots with the new multiline support.

At the moment, lines that are longer than the geometry allows are not breaked but truncated. Linebreaks will come in the near future, as well as the fix for html-escapes in the messages.

ninian · 2011-09-13 08:23:11

Many thanks - this is a great piece of work with a lot of potential for light systems.

Testing out dunst-git 20110913-1, the geometry options are working well, but I have found a couple of problems when you're just using -msg rather than notify-send.
1) Dunst takes over the CPU when you issue a message with -msg and it's waiting for the timeout.
2) If you issue one message with -msg, then you issue another (a separate command invocation, not a second -msg on the command line) while the first one is still on screen, there is a flickering contention between the two messages, and Dunst once again takes over the CPU!

Also, when running in daemon mode and issuing a message via notify-send, Dunst doesn't seem to obey notify-send's -t (timeout in milliseconds) option; the message stays forever until clicked.

Humble feature requests
- The ability for Dunst itself to issue a message via libnotify, not just directly via the -msg option. (A kind of dunst-send rather than using notify-send?!)
- Xft support (a la Dmenu?!)

All the best with your exams.

Last edited by ninian (2011-09-13 09:30:22)

knopwob · 2011-09-13 09:35:37

ninian wrote:

Many thanks - this is a great piece of work with a lot of potential for light systems.

Thank you

ninian wrote:

Testing out dunst-git 20110913-1, the geometry options are working well, but I have found a couple of problems when you're just using -msg rather than notify-send.
1) Dunst takes over the CPU when you issue a message with -msg and it's waiting for the timeout.

I just pushed a small change that should fix this.

ninian wrote:

2) If you issue one message with -msg, then you issue another (a separate command invocation, not a second -msg on the command line) while the first one is still on screen, there is a flickering contention between the two messages, and Dunst once again takes over the CPU!

The cpu issue in this case should be fixed aswell, but the windows are still broken. I'll look into that.

ninian wrote:

Humble feature request: Xft support (a la Dmenu?!)
All the best with your exams.

Another thing I'll take a look at at the weekend and thank you.

ninian · 2011-09-13 11:19:48

What a swift and positive response! I look foward to testing out the fixes this evening.

One further query:
When using the daemon, the name of the program which initiates the notification appears first on the notification line, followed by a colon. This usually works fine (eg Thunderbird:), but there are some times when you want to override or suppress this name. For example, when using notify-send, it's not very attractive for users to see:

notify-send: Warning -- This is the message text

For the average users I support, it would look better just dropping the 'notify-send: ' part altogether. I'm not sure how this can be solved, but would a special override/suppress option in the case of notify-send be sensible?

knopwob · 2011-09-13 12:16:46

ninian wrote:

What a swift and positive response! I look foward to testing out the fixes this evening.
One further query:
When using the daemon, the name of the program which initiates the notification appears first on the notification line, followed by a colon. This usually works fine (eg Thunderbird:), but there are some times when you want to override or suppress this name. For example, when using notify-send, it's not very attractive for users to see:
notify-send: Warning -- This is the message text
For the average users I support, it would look better just dropping the 'notify-send: ' part altogether. I'm not sure how this can be solved, but would a special override/suppress option in the case of notify-send be sensible?

This fits to a feature I was and still am thinking about to implement. My idea was to add the ability to add filters on messages (name of the application, string in the message and so on) and change the behaviour of dunst accordingly. One example of this would be different colors for messages from different applications. Or as you pointed out, change the format of the message.

But I don't want to just add features 'because I can'. I try to tradeoff the complexity (of the source code as well as configuration) against the usefullness of the feature and I'm still struggling with that on my idea of filters. So any input on this one, for example how useful this would be for you, what things you would do with such a feature and so on, would be very helpful for me to make a decision on this one.

Independent of what decision I make, I first focus on fixing the existing issues (multiple dunst windows interfering with each other and fix html-escapes in messages...), before I'll add new features.

ninian · 2011-09-13 15:45:36

Aha ... you're well ahead of me there! I completely appreciate your priorities. But here are my thoughts ...

I think the two functions of Dunst need to be considered almost separately:

1) The daemon function, which for compatibility should follow the Desktop Notifications Specification as far as the Dmenu-ish programming allows (eg, probably no icons!). This would allow Dunst to be used as a lightweight drop-in replacement for notification-daemon, xfce4-notifyd, etc. In particular, notify-send should produce similar notification messages with Dunst as can be achieved with the other notification daemons (including timeout options, eg critical messages remain on screen, but others timeout with the normal defaults or whatever is specified with the -to option).

Having different colours for different calling applications wouldn't be of much use to me, because it's the category of message which is usually more important than the application name itself. For example, a reminders program can issue standard or urgent reminders. I might like the ordinary ones in blue, but the urgent ones in red.

2) The direct messaging function, using -msg, can be formatted much more flexibly as it doesn't need to conform to the standard above. But as long as it produces similar results which "fit in" with the notifications produced by the Dunst daemon, I'd be happy, no matter the bells and whistles available for formatting the message.

At the moment I use dzen2 for home-made notifications, categorized by different colours and timeouts into: errors (with or without an alarm bell), warnings, information messages, standard messages. Other formal notifications (from Thunderbird, Osmo, etc) are handled by xfce4-notifyd. What I'd love is just to use Dunst for everything, probably via notify-send.

Hope this makes some sense!

knopwob · 2011-09-13 16:59:04

you've got good points here.

ninian wrote:

Aha ... you're well ahead of me there! I completely appreciate your priorities. But here are my thoughts ...
I think the two functions of Dunst need to be considered almost separately:
1) The daemon function, which for compatibility should follow the Desktop Notifications Specification as far as the Dmenu-ish programming allows (eg, probably no icons!). This would allow Dunst to be used as a lightweight drop-in replacement for notification-daemon, xfce4-notifyd, etc. In particular, notify-send should produce similar notification messages with Dunst as can be achieved with the other notification daemons (including timeout options, eg critical messages remain on screen, but others timeout with the normal defaults or whatever is specified with the -to option).

complying to specifications is always a good thing I think, we are on the same page concerning urgency-levels and timeouts. This will be implemented in the near future.
About the issue with notify-send's name being displayed. It don't like the idea of hardcoding an exception for one application. As far as I know, no other notification daemon displays the name of the Application, which sended the message. But actually I like it. So how about making it optional. I've got something like this in mind:

dunst -format "%a: %s -- %b"   <-- This would be the current state
%a -> application name
%s -> summary
%b -> message body.

This way, if you don't want the application name displayed, you could change the option to something like this:

dunst -format "%s: %b"

This way only the summary and the body of the message will be displayed. As it is (as far as I know) the state with the other notification-daemons around.

ninian wrote:

Having different colours for different calling applications wouldn't be of much use to me, because it's the category of message which is usually more important than the application name itself. For example, a reminders program can issue standard or urgent reminders. I might like the ordinary ones in blue, but the urgent ones in red.

Yes I agree with you that there should be a visual clue for the urgency-level of a message. I guess an additional option for the color of urgend messages would be appropriate.
At this point I think I should also think about adding a config file, because the commandline could grow fairly large if you use all the available options.

ninian wrote:

2) The direct messaging function, using -msg, can be formatted much more flexibly as it doesn't need to conform to the standard above. But as long as it produces similar results which "fit in" with the notifications produced by the Dunst daemon, I'd be happy, no matter the bells and whistles available for formatting the message.
At the moment I use dzen2 for home-made notifications, categorized by different colours and timeouts into: errors (with or without an alarm bell), warnings, information messages, standard messages. Other formal notifications (from Thunderbird, Osmo, etc) are handled by xfce4-notifyd. What I'd love is just to use Dunst for everything, probably via notify-send.

I guess this is where you found the issue about multiple messages being displayed on top of each other? As soon as I found a way to make dunst notice, that there's already a message displayed by another instance of dunst and make it act accordingly (either add the message to the existing message or add another message next to it) this should be possible.

Last edited by knopwob (2011-09-13 17:00:03)

ninian · 2011-09-13 18:17:58

knopwob wrote:

complying to specifications is always a good thing I think, we are on the same page concerning urgency-levels and timeouts. This will be implemented in the near future.
About the issue with notify-send's name being displayed. It don't like the idea of hardcoding an exception for one application. As far as I know, no other notification daemon displays the name of the Application, which sended the message. But actually I like it. So how about making it optional. I've got something like this in mind:
dunst -format "%a: %s -- %b"   <-- This would be the current state
%a -> application name
%s -> summary
%b -> message body.
This way, if you don't want the application name displayed, you could change the option to something like this:
dunst -format "%s: %b"
This way only the summary and the body of the message will be displayed. As it is (as far as I know) the state with the other notification-daemons around.

Yes, I like this formatting idea, and indeed optionally showing the application's name is in the spec at http://www.galago-project.org/specs/not … 9/x81.html, but as you say, other daemons don't even offer you a choice. Most times I'd like the application name displayed too, and I agree that hardcoding an exception for notify-send is a poor idea. Interestingly, the spec says: 'This should be the application's formal name, rather than some sort of ID. An example would be "FredApp E-Mail Client," rather than "fredapp-email-client."' Wonder what the formal name for notify-send is?!

knopwob wrote:

At this point I think I should also think about adding a config file, because the commandline could grow fairly large if you use all the available options.

Ah well, you know your program has really arrived on the scene when you need to add a config file!

knopwob wrote:

I guess this is where you found the issue about multiple messages being displayed on top of each other? As soon as I found a way to make dunst notice, that there's already a message displayed by another instance of dunst and make it act accordingly (either add the message to the existing message or add another message next to it) this should be possible.

Ha ha, you're dead right! Message on top of message on top of message on top of message ....

Thanks so much for taking these points on board and I look forward to future developments.

chneukirchen · 2011-09-14 18:11:02

knopwob wrote:

But as I stated in the post before: don't expect anything before the weekend. I have a written exame about database programming on thursday which I have to focus on (even though I don't want to )

Wow, all my wishes implemented. You rock, knopwob!

Sirsurthur · 2011-09-15 19:30:20

Hi knopwob,

I really like dunst and have two questions :

1- Is it possible not to show the "notify-send : " before the real notification ?

2- Is dunst able to deal with utf-8 and all the strange character ?

Thanks a lot for your answers.

Best regards,

Sirsurthur

knopwob · 2011-09-15 20:01:34

Sirsurthur wrote:

1- Is it possible not to show the "notify-send : " before the real notification ?

the 'notify-send' seems to annoy a lot of people
To answer your question: No not at the moment. But I'm currently working on a few things on my todo list. If everything works out i've got a batch of new features ready later this night and not displaying the application name is hopefully one of them. See my last post for more information on how it will work.

Sirsurthur wrote:

2- Is dunst able to deal with utf-8 and all the strange character ?

To be honest I'm not sure. It depends on the underlying Xlib that is used. But at least the german umlauts are correctly shown. If you encounter any problems with utf-8 characters not being correctly displayed, let me know and I'll look further into it.

chneukirchen · 2011-09-15 23:39:18

Sirsurthur wrote:

2- Is dunst able to deal with utf-8 and all the strange character ?

Works fine, if you use a unicode-capable font (i.e. not the default "fixed", but e.g. "-*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-1"): http://imgur.com/wf5r0.png

Arch Linux

#1 2011-09-07 12:47:15

dunst - a dmenu-ish notification daemon

#2 2011-09-08 20:10:21

Re: dunst - a dmenu-ish notification daemon

#3 2011-09-08 20:56:22

Re: dunst - a dmenu-ish notification daemon

#4 2011-09-08 21:08:38

Re: dunst - a dmenu-ish notification daemon

#5 2011-09-08 21:12:27

Re: dunst - a dmenu-ish notification daemon

#6 2011-09-08 21:15:56

Re: dunst - a dmenu-ish notification daemon

#7 2011-09-08 22:46:26

Re: dunst - a dmenu-ish notification daemon

#8 2011-09-11 23:59:40

Re: dunst - a dmenu-ish notification daemon

#9 2011-09-12 09:13:35

Re: dunst - a dmenu-ish notification daemon

#10 2011-09-12 11:09:59

Re: dunst - a dmenu-ish notification daemon

#11 2011-09-12 11:38:08

Re: dunst - a dmenu-ish notification daemon

#12 2011-09-12 16:23:48

Re: dunst - a dmenu-ish notification daemon

#13 2011-09-12 17:16:14

Re: dunst - a dmenu-ish notification daemon

#14 2011-09-12 23:20:57

Re: dunst - a dmenu-ish notification daemon

#15 2011-09-13 08:23:11

Re: dunst - a dmenu-ish notification daemon

#16 2011-09-13 09:35:37

Re: dunst - a dmenu-ish notification daemon

#17 2011-09-13 11:19:48

Re: dunst - a dmenu-ish notification daemon

#18 2011-09-13 12:16:46

Re: dunst - a dmenu-ish notification daemon

#19 2011-09-13 15:45:36

Re: dunst - a dmenu-ish notification daemon

#20 2011-09-13 16:59:04

Re: dunst - a dmenu-ish notification daemon

#21 2011-09-13 18:17:58

Re: dunst - a dmenu-ish notification daemon

#22 2011-09-14 18:11:02

Re: dunst - a dmenu-ish notification daemon

#23 2011-09-15 19:30:20

Re: dunst - a dmenu-ish notification daemon

#24 2011-09-15 20:01:34

Re: dunst - a dmenu-ish notification daemon

#25 2011-09-15 23:39:18

Re: dunst - a dmenu-ish notification daemon

Board footer