Feature request: better queue control

[ralismark]

I've recently switched from dunst to eventd, and this is quite good. However, there are a few features that dunst has but eventd doesn't that would be great:

• Temporary pausing of a queue (and showing all notifications after)
• Showing past notifications

These could be implemented as eventdctl commands. How hard would these be to implement?

[sardemff7]

Glad to hear you like eventd so far.

Pausing

This part is in the context of eventd as a whole, not just as a notification daemon.

Pausing is on my TODO list for a long time now, and I have thought a lot on how to integrate it to eventd’s overall design.
The feature even existed at some point but it didn’t fit well with the asynchronous and distributed flow.
I have one piece of the plan done already for quite some time now, which are flags.
My latest idea is to have actions delayed by flags presence/absence. So an example configuration would be:

notification.action:
    [Action]
    Name=notification
    DelayedIf=afk;
    [Notification]

(Actual key names and usage are WIP)

And you’d have an eventdctl flags add afk in your screensaver script or whatever. (I also want to implement a [Flags] action so you could just add/remove the flag based on some event, that could propagate and stuff.)

History

This part is about the notification daemon (libnotify) feature only and would require adjustments to be usable with notifications from other sources.

As of history, this is more or less a non-goal. But I hope that some time in the future I will be able to add some kind of “notification center”.
However, you can easily use the file plugin to create a JSON list of notifications. You can find an example here (not fully complete, it lacks a few hints that you may use). It uses rofi as a menu to manage the history. You can of course just have your own script read the history file, drop the line and pop the notification back (which will re-write it to the history file, as the file plugin just appends text, it doesn’t understand it).

[ralismark]

From what I can tell from the installed headers, there's no public API to interact with flags. Am I missing something?

[sardemff7]

You’re right, you can only interact with them via eventdctl flags currently. The core can touch them, and the [Flags] action would be in the core, probably (or in some plugin while I add API for that).
Do you have a plugin in mind that you (will) need flags API for?