dunst - a dmenu-ish notification daemon

knopwob · 2011-09-15 23:59:17

I just pushed a batch of changes to the repo.

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 ..., I would just skip these.)

this should be fixed now.

Added a -format option for all you guys who don't like the application name being displayed in the message. The default format doesn't contain the application name (see manpage for more informations).
Dunst now obeys the timeout if the message included one, otherwise the default timeout (-to) is used
Dunst now differentiats between the different urgency levels. For each level a different foreground and background color can be defined (again, see manpage). It's not clear in the specifications (at least not for me) if the server should always set the timeout of critical messages to 0 (don't timeout), or if the application should do this via the addition of the timeout option. At the moment dunst sets the default timeout to critical messages, if no timeout is supplied with the message

Please let me know if you encounter any problems with the new changes.

And on a site note: If you encounter any issues or have feature request and already have a github account, it would be nice if you could add it to the issue tracker there. This way it's much easier for me to keep track of everything.

Anyway, every feedback is appreciated.
Have Fun.

ninian · 2011-09-16 10:59:23

knopwob wrote:

I just pushed a batch of changes to the repo ... Have Fun.

That's great - have a gold star for all your work in such a short time!
Am really looking forward to trying out the new options this evening after work.
Will report back after then ...

ninian · 2011-09-16 18:36:16

Have been experimenting a bit with the latest updates and here are my comments so far:

- The -format option seems to work well (though I'm not sure how the %i and %I placeholders will be useful as they only display the name or path of the icon)
- The colour options for low, normal and critical messages are good. (The builtin default colours are acceptable, though part of me wonders whether the low and normal ones should be swapped round ... the grey background seems more "low" to me than the nice bluish one!)
- Timeouts are still a bit of a problem; the specification actually says that "Critical notifications should not automatically expire, as they are things that the user will most likely want to know about. They should only be closed when the user dismisses them, for example, by clicking on the notification." So the default timeout for critical messages should be infinite (timeout=0), but low and normal messages "should, however, have a sane expiration timeout" - this usually defaults to 10 seconds with other notification daemons. I think the only way to deal with this is to build in the defaults: critical=infinite (specify as 0), low=normal=10secs; and have 3 command line options to override the defaults for each category of urgency. How about: -lt, -nt and -ct (or -lto, -nto and -cto)?
- I had an alarm notified by Osmo, and it showed the HTML and tags; should they have been removed?
- If you issue a -msg command, and then invoke another -msg command (not two -msgs on the same command line), the second message gets "blanked" and only reappears when the first message times out. (This happens even if you specify -geometry to display over more than one line.) I'd expect -msg commands to produce notifications stacked up in the same way as if they had been sent using notify-send, etc.
- Oooh, I'm looking forward to Xft support if possible too (how greedy am I)!

Hope these observations are helpful. This is a great little project, especially as many other notification programs have taken up far too much memory - for example, who really needs the overhead of Python for this kind of thing? Bring on your C!

Last edited by ninian (2011-09-16 18:47:17)

knopwob · 2011-09-16 19:47:02

ninian wrote:

- The -format option seems to work well (though I'm not sure how the %i and %I placeholders will be useful as they only display the name or path of the icon)

Someone at github asked for them

ninian wrote:

- The colour options for low, normal and critical messages are good. (The builtin default colours are acceptable, though part of me wonders whether the low and normal ones should be swapped round ... the grey background seems more "low" to me than the nice bluish one!)

You have the option to change the defaults Actually I didn't put many thoughts into the default colors. I just needed different ones for testing. But to add reasoning after the fact: Think about the urgency as the "hotness" of the message. Blue is a cold message, grey a normal temperatured one and red a hot one.

ninian wrote:

- Timeouts are still a bit of a problem; the specification actually says that "Critical notifications should not automatically expire, as they are things that the user will most likely want to know about. They should only be closed when the user dismisses them, for example, by clicking on the notification." So the default timeout for critical messages should be infinite (timeout=0), but low and normal messages "should, however, have a sane expiration timeout" - this usually defaults to 10 seconds with other notification daemons. I think the only way to deal with this is to build in the defaults: critical=infinite (specify as 0), low=normal=10secs; and have 3 command line options to override the defaults for each category of urgency. How about: -lt, -nt and -ct (or -lto, -nto and -cto)?

You're liking insanly long commandlines, aren't you But let's be serious again. As I stated above, the specification doesn't clarify who's responsible to set the timeout on critical messages. But if you have clients, that don't set the timeout on critical messages to 0, then I guess the server should do so. So yes, I'll change that. And while I'm already on it, i can also add two more options. This raises another issue. At the moment, dunst only recognized that the message box has been clicked on, but it doesn't know which message exactly. So at the moment, the oldest message will be deleted. That's another thing I have to work on.

ninian wrote:

- I had an alarm notified by Osmo, and it showed the HTML and tags; should they have been removed?

They should be removed, but dunst doesn't at the moment. That's a new issue on my todo-list.

ninian wrote:

- If you issue a -msg command, and then invoke another -msg command (not two -msgs on the same command line), the second message gets "blanked" and only reappears when the first message times out. (This happens even if you specify -geometry to display over more than one line.) I'd expect -msg commands to produce notifications stacked up in the same way as if they had been sent using notify-send, etc.

Yeah, I didn't have a chance to work on this, yet. My plan for this is, if you're using -msg option and dunst detects another notification daemon running, it issues a notification to the server and adding the color informations as hints. And if the server is dunst, it will change the color of the message accordingly.

ninian wrote:

- Oooh, I'm looking forward to Xft support if possible too (how greedy am I)!

At least I can't complain that I have nothing to do

ninian wrote:

Hope these observations are helpful. This is a great little project, especially as many other notification programs have taken up far too much memory - for example, who really needs the overhead of Python for this kind of thing? Bring on your C!

I can totally understand everyone who prefers to write something like this in any language other than c. Dbus is not meant to be used with c but with a higher level language. To quote the dbus documentation:

dbus wrote:

This manual documents the low-level D-Bus C API. If you use this low-level API directly, you're signing up for some pain.

Last edited by knopwob (2011-09-16 20:25:47)

ninian · 2011-09-16 20:28:20

Thanks for your quick response!

knopwob wrote:

Actually I didn't put many thoughts into the default colors. I just needed different ones for testing. But to add reasoning after the fact: Think about the urgency as the "hotness" of the message. Blue is a cold message, grey a normal temperatured one and red a hot one.

LOL ... as a former physicist, I'll buy that explanation!

knopwob wrote:

You're liking insanly long commandlines, aren't you ... But if you have clients, that don't set the timeout on critical messages to 0, then I guess the server should do so. So yes, I'll change that. And while I'm already on it, i can also add two more options. This raises another issue. At the moment, dunst only recognized that the message box has been clicked on, but it doesn't know which message exactly. So at the moment, the oldest message will be deleted.

Ah well, you just run the dunst daemon command once a session (ideally) so it's no hassle to have a lot of parameters! Must admit, I never realized that only the oldest message got deleted; but it does make sense, sort of ...

knopwob wrote:

They (HTML tags) should be removed, but dunst doesn't at the moment. That's a new issue on my todo-list.

Would just help to tidy things up, I suppose.

knopwob wrote:

My plan for this is, if you're using -msg option and dunst detects another notification daemon running, it issues a notification to the server and adding the color informations as hints. And if the server is dunst, it will change the color of the message accordingly.

That's cunning, so that's what hints are about - never really understood them before.

knopwob wrote:

I can totally understand everyone who prefers to write something like this in any language other than c. Dbus is not meant to be used with c but qirh a higher level language. To quote the dbus documentation:
dbus wrote:
This manual documents the low-level D-Bus C API. If you use this low-level API directly, you're signing up for some pain.

I honestly salute your bravery ... it's a pity if D-Bus is such a PITA.

Having junked xfce4-notifyd in favour of the new dunst, I'm already enjoying the extra MBs of RAM which I've saved ... we have quite a few older computers here, so all your good work really helps to keep them going.

Last edited by ninian (2011-09-16 20:29:06)

knopwob · 2011-09-16 21:15:30

I've added your timeout options. But I also kept the old -to one, which now sets the timeout for both low and normal messages. And now the default urgency level for critical messages is 0, but can be overriden with -cto. But all values can be overriden by the client, if he defines another timeout for the message.

ninian wrote:

knopwob wrote:
They (HTML tags) should be removed, but dunst doesn't at the moment. That's a new issue on my todo-list.
Would just help to tidy things up, I suppose.

Now dunst does

ninian wrote:

knopwob wrote:
I can totally understand everyone who prefers to write something like this in any language other than c. Dbus is not meant to be used with c but qirh a higher level language. To quote the dbus documentation:
dbus wrote:
This manual documents the low-level D-Bus C API. If you use this low-level API directly, you're signing up for some pain.
I honestly salute your bravery ... it's a pity if D-Bus is such a PITA.

aah, don't exaggerate things. There are some examples around and the code of some other projects helped me figuring this stuff out.

ninian wrote:

Having junked xfce4-notifyd in favour of the new dunst, I'm already enjoying the extra MBs of RAM which I've saved ... we have quite a few older computers here, so all your good work really helps to keep them going.

It's always nice to keep old machines useful.

ninian · 2011-09-16 21:35:37

Latest updates are working great!
This is getting seriously useful and deserves wider exposure ...

ninian · 2011-09-17 16:17:28

Something fishy going on I'm afraid with critical notifications.
After loading the daemon thus:

dunst -geometry 0x4-0-0 &

Run a script containing:

for i in 1 2 3 4 5 6 7 8 9 10; do
  sleep 1
  notify-send -u normal "n=$i" "test $i" &
done
exit

and the messages are queued up and appear/disappear as you would expect.
But change the 'normal' to 'critical', wait until the script ends, then try clicking on the notification area.
Nothing seems to happen, but after about 6 clicks, the last notification appears at the bottom of the stack! What's happened to the display of the other 6 or so?!

Very curious!

knopwob · 2011-09-17 17:06:05

ninian wrote:

Something fishy going on I'm afraid with critical notifications.
After loading the daemon thus:
dunst -geometry 0x4-0-0 &
Run a script containing:
for i in 1 2 3 4 5 6 7 8 9 10; do
  sleep 1
  notify-send -u normal "n=$i" "test $i" &
done
exit
and the messages are queued up and appear/disappear as you would expect.
But change the 'normal' to 'critical', wait until the script ends, then try clicking on the notification area.
Nothing seems to happen, but after about 6 clicks, the last notification appears at the bottom of the stack! What's happened to the display of the other 6 or so?!

yeah, that's a bug. And the fix is already pushed to the repo.
Good catch on that one. I would have never noticed this.

ninian · 2011-09-17 21:32:31

knopwob wrote:

yeah, that's a bug. And the fix is already pushed to the repo.
Good catch on that one. I would have never noticed this.

You're welcome - and once again, thanks for the swift fix.
Looks good now!

chneukirchen · 2011-09-18 14:08:37

One more bug: "<3" said in Pidgin results in "<;3" being displayed by dunst.

I'm also tracking down a segfault, perhaps its related. But I could not yet reproduce in gdb.

knopwob · 2011-09-18 14:20:06

chneukirchen wrote:

One more bug: "<3" said in Pidgin results in "<;3" being displayed by dunst.

fixed, thank you.

chneukirchen wrote:

I'm also tracking down a segfault, perhaps its related. But I could not yet reproduce in gdb.

Please let me know, if you found a way to reproduce this.

chneukirchen · 2011-09-21 19:00:35

knopwob wrote:

chneukirchen wrote:
One more bug: "<3" said in Pidgin results in "<;3" being displayed by dunst.
fixed, thank you.
chneukirchen wrote:
I'm also tracking down a segfault, perhaps its related. But I could not yet reproduce in gdb.
Please let me know, if you found a way to reproduce this.

I can't reproduce but I have a backtrace:

Program received signal SIGSEGV, Segmentation fault.
check_timeouts () at dunst.c:188
188             if(cur->start == 0 || cur->timeout == 0) {
(gdb) bt
#0  check_timeouts () at dunst.c:188
#1  0x0000000000403dcf in run () at dunst.c:475
#2  0x000000000040290a in main (argc=19, argv=0x7fffffffe178) at dunst.c:665
(gdb) p cur
$1 = (msg_queue_t *) 0x1
(gdb) p msgqueue
$2 = (msg_queue_t *) 0x0

hth

EDIT: possibly fixed in ba6c00ba already.

Last edited by chneukirchen (2011-09-21 19:02:06)

chneukirchen · 2011-09-23 15:12:32

Still happened again with f84ace2b05d8:

Program received signal SIGSEGV, Segmentation fault.
check_timeouts () at dunst.c:188
188             if(cur->start == 0 || cur->timeout == 0) {
(gdb) bt
#0  check_timeouts () at dunst.c:188
#1  0x0000000000403dcf in run () at dunst.c:475
#2  0x000000000040290a in main (argc=19, argv=0x7fffffffe198) at dunst.c:665
(gdb) p cur
$1 = (msg_queue_t *) 0x2
(gdb) p msgqueue 
$2 = (msg_queue_t *) 0x0
(gdb)

Ok, can reproduce easily now:

% gdb ./dunst
(gdb) b check_timeouts 
Breakpoint 1 at 0x4030ae: file dunst.c, line 184.
(gdb) r
Starting program: /tmp/packerbuild-1000/dunst-git/dunst-git/src/dunst/dunst 
[Thread debugging using libthread_db enabled]
foo bar (timeout: 10, urgency: 1)

Breakpoint 1, check_timeouts () at dunst.c:184
184     check_timeouts(void) {
(gdb) p msgqueue 
$1 = (msg_queue_t *) 0x607030
(gdb) p *msgqueue 
$2 = {msg = 0x60d0f0 "foo bar", next = 0x0, start = 1316791371, timeout = 10, 
  urgency = 1}
(gdb) c
Continuing.

Breakpoint 1, check_timeouts () at dunst.c:184
184     check_timeouts(void) {
(gdb) p *msgqueue 
$3 = {msg = 0x60d0f0 "foo bar", next = 0x0, start = 1316791371, timeout = 10, 
  urgency = 1}
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
check_timeouts () at dunst.c:188
188             if(cur->start == 0 || cur->timeout == 0) {
(gdb) p *msgqueue 
Cannot access memory at address 0x0
(gdb)

In parallel, I ran notify-send once.

Last edited by chneukirchen (2011-09-23 15:26:26)

chneukirchen · 2011-09-23 16:19:09

I really seem to suck debugging. It must be related to the free(elem) in line 134, but I just can't find the place that still refers to the address.

ninian · 2011-09-23 17:30:49

If you're using the -msg option, then -nb and -nf allow you to change the colours for the message. But correspondingly, -nto doesn't change the timeout - it always defaults to 10 seconds. (Just checked too that -to doesn't change this default either when using -msg.)

chneukirchen · 2011-09-23 22:00:21

Got it: cur->next is undefined in check_timeouts after delete_msg(cur), because cur is freed by then already.

This patch fixes it, but perhaps someone has a nicer idea:

@@ -182,14 +183,16 @@ int list_len(msg_queue_t *list) {
 
 void
 check_timeouts(void) {
-    msg_queue_t *cur;
+    msg_queue_t *cur, *here;
 
-    for(cur = msgqueue; cur != NULL; cur = cur->next) {
+    for(cur = msgqueue; cur != NULL; ) {
         if(cur->start == 0 || cur->timeout == 0) {
             continue;
         }
-        if(difftime(now, cur->start) > cur->timeout) {
-            delete_msg(cur);
+        here = cur;
+        cur = cur->next;
+        if(difftime(now, here->start) > here->timeout) {
+            delete_msg(here);
         }
     }
 }

And I think you also want:

@@ -159,6 +159,7 @@ pop(msg_queue_t *queue) {
         return NULL;
     }
     if(queue->next == NULL) {
+        free(queue->msg);
         free(queue);
         return NULL;
     }

knopwob · 2011-09-23 23:45:30

ninian wrote:

If you're using the -msg option, then -nb and -nf allow you to change the colours for the message. But correspondingly, -nto doesn't change the timeout - it always defaults to 10 seconds. (Just checked too that -to doesn't change this default either when using -msg.)

does by any chance the -nto come _after_ the -msg option? if you change the order so that -to/-nto comes before the -msg it should work. At the moment I'm not sure, if I will fix this, because I'm thinking about removing the -msg option completely. I just added the ability to read the colors from the hints of the notification. So now you can set the color of a message via notify-send:

notify-send -h string:bgcolor:#4444ff -h string:fgcolor:#ff4444

This looks a bit ugly, but now you can do everything via notify-send what you have done previously via -msg (unless I have forgotten something). I know, I've said before, that I will add the ability to dunst to check wether there's already a daemon running and in that case send a notification by himself, but to be honest, I'm not really motivated to implement that.

chneukirchen wrote:

Got it: cur->next is undefined in check_timeouts after delete_msg(cur), because cur is freed by then already.
This patch fixes it, but perhaps someone has a nicer idea:

@@ -182,14 +183,16 @@ int list_len(msg_queue_t *list) {
 
 void
 check_timeouts(void) {
-    msg_queue_t *cur;
+    msg_queue_t *cur, *here;
 
-    for(cur = msgqueue; cur != NULL; cur = cur->next) {
+    for(cur = msgqueue; cur != NULL; ) {
         if(cur->start == 0 || cur->timeout == 0) {
             continue;
         }
-        if(difftime(now, cur->start) > cur->timeout) {
-            delete_msg(cur);
+        here = cur;
+        cur = cur->next;
+        if(difftime(now, here->start) > here->timeout) {
+            delete_msg(here);
         }
     }
 }

Thank you for figuring this out. I'm just a bit confused why you where the only one who got segfaults. Did you change the compiler options or something?
I reworked your patch a bit and commited the changes to the repo.

chneukirchen wrote:

And I think you also want:

@@ -159,6 +159,7 @@ pop(msg_queue_t *queue) {
         return NULL;
     }
     if(queue->next == NULL) {
+        free(queue->msg);
         free(queue);
         return NULL;
     }

Yes, you're right.

chneukirchen · 2011-09-24 13:28:30

knopwob wrote:

Thank you for figuring this out. I'm just a bit confused why you where the only one who got segfaults. Did you change the compiler options or something?

I compiled with -g and without optimization, but the segfault only occurred in gdb when I had a breakpoint on check_timeouts. But valgrind repeatedly noticed it, in all cases.

chneukirchen · 2011-09-24 16:00:03

Another feature request Multi-line messages get displayed with weird "VT"-symbols, e.g

notify-send foo "bar
quux"

ninian · 2011-09-24 16:46:06

knopwob wrote:

does by any chance the -nto come _after_ the -msg option? if you change the order so that -to/-nto comes before the -msg it should work. At the moment I'm not sure, if I will fix this, because I'm thinking about removing the -msg option completely. I just added the ability to read the colors from the hints of the notification. So now you can set the color of a message via notify-send:
notify-send -h string:bgcolor:#4444ff -h string:fgcolor:#ff4444
This looks a bit ugly, but now you can do everything via notify-send what you have done previously via -msg (unless I have forgotten something). I know, I've said before, that I will add the ability to dunst to check wether there's already a daemon running and in that case send a notification by himself, but to be honest, I'm not really motivated to implement that.

Ah yes, you're dead right - I had specified -to/-nto after the -msg option.
I think what you've done with the colour hints is great and it does seem to make the -msg option rather redundant if you can just use notify-send for everything now. The only other thing which I'd appreciate very much is Xft support ...

chneukirchen wrote:

Multi-line messages get displayed with weird "VT"-symbols

I forgot to mention this too; you get a "VT" symbol where the newline was. With the dunst daemon running, I tested this out in a script:

x="line1
line2
line3"
notify-send "Test" "$x"

knopwob wrote:

I'm just a bit confused why you where the only one who got segfaults.

Curiously, the very first dunst I tried produced a segfault, but never since ... until now when using the -msg option! Here's my totally inexperienced attempt at trying to use the debugger:

$ gdb dunst
...
(gdb) run -msg "first" -msg "second"
Starting program: /usr/bin/dunst -msg "first" -msg "second"
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0804ac3f in ?? ()
(gdb) bt
#0  0x0804ac3f in ?? ()
#1  0x08049d5c in ?? ()
#2  0xb7cc6223 in __libc_start_main () from /lib/libc.so.6
#3  0x08049fcd in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

Does this help at all?!

Last edited by ninian (2011-09-24 16:50:27)

chneukirchen · 2011-09-26 13:45:28

Remove the -s from LDFLAGS in config.mk to not strip debugging information:

% gdb ./dunst
(gdb) r -msg a -msg b
Starting program: /tmp/packerbuild-1000/dunst-git/dunst-git/src/dunst-build/dunst -msg a -msg b
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
append (queue=0x0, msg=<optimized out>, to=-1, urgency=1, fg=0x0, bg=0x0)
at dunst.c:100
100 Colormap cmap = DefaultColormap(dc->dpy, DefaultScreen(dc->dpy));
(gdb) bt
#0 append (queue=0x0, msg=<optimized out>, to=-1, urgency=1, fg=0x0, bg=0x0)
at dunst.c:100
#1 0x00000000004026e4 in main (argc=5, argv=0x7fffffffe258) at dunst.c:631
(gdb) p dc
$1 = (DC *) 0x0

ninian · 2011-09-26 14:17:27

chneukirchen wrote:

Remove the -s from LDFLAGS in config.mk to not strip debugging information

Aaaaaah, thank you!

knopwob · 2011-09-27 14:24:51

chneukirchen wrote:

Another feature request Multi-line messages get displayed with weird "VT"-symbols, e.g
notify-send foo "bar
quux"

For the moment dunst replaces newlines with spaces.

ninian wrote:

Curiously, the very first dunst I tried produced a segfault, but never since ... until now when using the -msg option!

aehm, ya. Let's say, it's my subconcious' way to tell me to remove the -msg option. Which I have done. So make sure you replace all dunst -msg calls with apropriate notify-sends, before you update.

ninian · 2011-09-27 15:16:18

knopwob wrote:

For the moment dunst replaces newlines with spaces.

That's the odd thing, it doesn't replace a newline with a space on my system (en_GB locale), but with a curious character which comprises a V on top of a T!

Arch Linux

#26 2011-09-15 23:59:17

Re: dunst - a dmenu-ish notification daemon

#27 2011-09-16 10:59:23

Re: dunst - a dmenu-ish notification daemon

#28 2011-09-16 18:36:16

Re: dunst - a dmenu-ish notification daemon

#29 2011-09-16 19:47:02

Re: dunst - a dmenu-ish notification daemon

#30 2011-09-16 20:28:20

Re: dunst - a dmenu-ish notification daemon

#31 2011-09-16 21:15:30

Re: dunst - a dmenu-ish notification daemon

#32 2011-09-16 21:35:37

Re: dunst - a dmenu-ish notification daemon

#33 2011-09-17 16:17:28

Re: dunst - a dmenu-ish notification daemon

#34 2011-09-17 17:06:05

Re: dunst - a dmenu-ish notification daemon

#35 2011-09-17 21:32:31

Re: dunst - a dmenu-ish notification daemon

#36 2011-09-18 14:08:37

Re: dunst - a dmenu-ish notification daemon

#37 2011-09-18 14:20:06

Re: dunst - a dmenu-ish notification daemon

#38 2011-09-21 19:00:35

Re: dunst - a dmenu-ish notification daemon

#39 2011-09-23 15:12:32

Re: dunst - a dmenu-ish notification daemon

#40 2011-09-23 16:19:09

Re: dunst - a dmenu-ish notification daemon

#41 2011-09-23 17:30:49

Re: dunst - a dmenu-ish notification daemon

#42 2011-09-23 22:00:21

Re: dunst - a dmenu-ish notification daemon

#43 2011-09-23 23:45:30

Re: dunst - a dmenu-ish notification daemon

#44 2011-09-24 13:28:30

Re: dunst - a dmenu-ish notification daemon

#45 2011-09-24 16:00:03

Re: dunst - a dmenu-ish notification daemon

#46 2011-09-24 16:46:06

Re: dunst - a dmenu-ish notification daemon

#47 2011-09-26 13:45:28

Re: dunst - a dmenu-ish notification daemon

#48 2011-09-26 14:17:27

Re: dunst - a dmenu-ish notification daemon

#49 2011-09-27 14:24:51

Re: dunst - a dmenu-ish notification daemon

#50 2011-09-27 15:16:18

Re: dunst - a dmenu-ish notification daemon

Board footer