Revision of signal handling

[cdlscpmv]

I've read #8, and I see that there are two distinct use cases for signal handling:

1. Interactive: you want to process one message at time (the first one).
2. Non-interactive: you want to act on all notifications at once.

Current behavior:

• SIGUSR1 kills all notification, which makes sense when used in non-interactive way.
• SIGUSR2 acts upon the first notification and kills the rest.

In my opinition, the current handling of SIGUSR2 isn't good for anything, because

For interactive use:

• The message that you want to act upon won't necessarily be the first one.
• You may want to act on more than one of the currently displayed notications, which is especally useful for notification without timeout.

Non-interactive use:

• I can't see any non-interactive use case for this signal.

Proposed behavior:

1. SIGUSR1 kills the first notification.
2. SIGUSR2 acts upon the first notification.
3. SIGHUP kills all notifications.

SIGUSR1 and SIGUSR2 are for interactive use, and SIGHUP is for scripts.

The users that rely on the current signal behavior won't be severely affected by this change (only those who want to close all notifications at once will have to replace SIGUSR1 with SIGHUP in their scripts).

[phillbush]

That's a good signal interface.
I'm gonna implement signal handling as you're proposing.