Feature request: additional script option to enable running script when paused

[jbwar22]

It would be nice to either have an option similar to always_run_script to enable a script to run while dunst is paused, or have an option for a secondary script that runs when a notification is received by dunst, but not necessarily displayed due to being paused.

Mentioned in #1099 although I believe this is not (and should not be) intended behavior for always_run_script = true as it only mentions suppressed notifications

Use case:
I have a notification widget that shows the number of waiting dunst notifications when I have dunst paused. Instead of polling dunst every second to get the waiting count, it would be nicer to let dunst alert the widget via a script.

[jbwar22]

I've spent some time looking through the code and implementing a rough patch that solves my use case and I have come to a few conclusions:

• Instead of necessarily implementing the options specified above, the overall goal should be to have more fine-grained control over when a specific script runs.
• In the current system, every script from a rule that matches a notification is aggregated together in an array. The code only has a way to run all scripts together, therefore individual script control requires a slight refactor.
• Maintaining the behavior of the current always_run_script property requires a bit of attention. Mainly, if we are defining exactly how and when a script runs, how do we describe it with a combination of properties?

On the last point, I think some careful consideration needs to be put into how properties related to scripts work. Say for example I wanted all notifications (configured via the global rule) to have both a script that runs on notification queue insert, and a script that runs on notification display. For this use case, it might be useful to have a secondary script property, called something like insert_script so that I could define both scripts in the global rule block. This would also make it trivial to maintain behavior of always_run_script, and it would allow the creation of another property always_run_insert_script, giving even more control over script behavior.

My rough patch makes no changes to properties, implements insert_scripts in the notifications struct, and assumes that all globally defined script is actually an insert_script, which is all I needed for my use case. I want to discuss what the right implementation direction is, and more importantly, if this feature is wanted, before I write something actually decent.

[bynect]

Hello, thanks for looking into it. I agree with you, the scripting mechanism is a bit of a mess right now. Some time ago there was a pr for advanced scripting #1072. Unfortunately it was not merged.

I was planning to revive it in some form when I change the rule properties handling.

I'm not too sure about insert_script because it seems a little bit restrictive to add a property type for every point a script could run. But I'll to think about this through

[jbwar22]

Thanks for the reply!

That makes sense, only having two script "entry points" is probably a bit shortsighted. It was all I really needed for my own rough patch / use case, but generalizing it somehow would definitely be better in the long run

I'll take a look at that PR

[jbwar22]

Seems like my use case can be covered by the "event rule" specified in #879 and seemingly attempted in #1072, so I'll close this.

I'd be happy to help work on a revisit of #1072 when work starts moving on it, so if you could mention me in whatever issue/pr that gets used, that'd be great. For now I can live with my fork

[bynect]

I think we can leave it open for the time being