-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interrupt a notification using script #906
Comments
No, that's not yet possible. Something # like a script that runs before the notification is shown could help. |
yeah, we could just termminate the current dunst process in it, any plan of implementing it ? I could try to take a look it |
nevermind, its working if you set the script in config first, and then put summary="" |
Does that fit your use case? I thought you wanted to dynamically change it. Of course that's possible when automatically changing the config and restarting dunst. #719 would probably help. I'll be working on that soon™ |
I mean, In the script I can just create another notification using the parameters. so yeah, it solved my problem |
Hi, I'm also looking into this - I want to "implement" some DND mode where some notifications will go through, some will also make a sound etc... And I want this to be dynamic, without needing to prepare 2 configurations and swap them around etc... The idea behind this is that I used Macos for 4 years and its notification handling was quite nice and I do miss some "system-wide" way of telling that e.g. mail application should be quiet (damn you, Thunderbird) except for mails with high priority set etc. Basically I thought about 2 approaches:
Option no. 2 would allow for much better customization (on-the-fly priority override for something etc) but I'd need to properly sanitize the input of course. Both of these would require for notifications to "wait" for the script (maybe it would be worth to create new option instead of Am I alone in this? I'm asking because if you might want to merge this feature, I'd spend the time to make this "nicer" - otherwise I'd just hack it in fast'n'furious style 😆 |
Hi @xoores, Cool that you want to work on this. A number of other people have been requesting a do not disturb mode. There is of course mako supports applying style options conditionally via modes. A configuration section with a mode criteria will only be applied if the current mode matches.
makoctl(1) can be used to change the current mode.
The default mode is named "default".
For example, to hide all notifications if the mode "do-not-disturb" is enabled:
[mode=do-not-disturb]
invisible=1
makoctl set-mode do-not-disturb will hide all notifications, makoctl set-mode default will show them again. This is easier to configure than making tons of scripts and it's almost as flexible. It shouldn't be too hard to implement either. We could even add an option to delay notifications, just like when dunst is pause, so you can read the missed notifications back. Take a look at #865 as well. Do you think this would be a good way to do it? |
Hi @fwsmit I looked at that issue 🙂 yeah, pause will just stop all the notifications. I looked at Mako (don't have Wayland so didn't know about that one) and it seems that it can apply some property to all notifications based on "mode". Meaning it is not dynamic in a way that would allow you to say e.g. "don't show notifications from mail unless they are important" etc. Dunst has similar logic but "inverted" to this by matching on sections but it basically does the same. I think that Dunst could replicate this by letting you enable/disable sections at runtime. I think that allowing scripts to alter the notifications would open up almost limitless possibilities. Honestly I would suggest to keep the Of course it is also possible that I completely misunderstood Mako's manpage and it is more powerful that it seems now 🙂 If that is the case, please correct me. If I understood Mako correctly, what would you say to the |
Depending on how you know if an email is important it's possible. First, there is How would you know if an email is important? Could you for example match it with regex based on the summary?
With the modes as they work in mako, you could set a "do no disturb mode", but it would not be suited for do not disturb for individual applications, each of them being individually toggle-able. You could make it so that a new mode doesn't replace the old one, e.g. multiple modes can be active, but that would be more complicated to implement and use. You'd be delighted to know that you can toggle rules with
As I said above, you can set that per section (as a filtering rule). Why did you think it was not? Could the documentation about it be improved?
There is a proposal that relates to running scripts before a notification #879. I agree this is the most flexible solution, but it's not the easiest to use. Also, there is currently no good way for scripts to edit a notification's properties. So if your use case is covered by the modes, then I would suggest that. |
Sorry for the delay, had quite a lot of things that I had to deal with 🙂 Important email could be determined by some "VIP" people for example - basically regexing notification. But the thing is not to only run with simple filtering because I ran into more painpoints in regards to notifications:
I don't think that dunst can do that with rules/modes alone. And it would also be untrivial to try to invent a way to put it directly into the config. Hence the proposition for scripting which could be used by someone who really wants to dig deep 🙂 Regarding the way to change values: I would try to go with editting ENV variables passed to the script with some rudimentary checks around that. Should be good and easy enough for proof-of-concept, we can also ignore invalid changes (use the original value instead). Also it would be easily expandable in the future. I missed that you can toggle rules, I love it! Is there a way to check whether rule is enabled or disabled? |
Not yet. You can implement it if you want :) |
Yeah I get that you cannot do everything with the rule functionality of dunst. For some thinks you really need a script. There exists already an issue about that: #899 |
I have proof-of-concept of editting notifications from shell script 😁 I will add this check also, but first I will finish up this so you can take a look at it & discuss potential direction of it. For now I went with MMAP as it is the easiest way but in the end I'd go for pthreads etc. 🙂 |
Cool, I'll take a look when you post something. |
I'll clean it up a little bit and push it to my branch. For now I crammed everything in notification.c but final solution (mergeable) would have to be in its own sourcefile (if we would want to keep 100% backwards compatibility by leaving If you'd decide to just change the script to be blocking, I could leave it in there - I basically added As for now it looks something like this: Script: #!/bin/bash
# Simulate some heavy work that takes time
sleep .3
export DUNST_FORMAT="<i>%s</i>\n%b"
export DUNST_TIMEOUT=1000 Result in dunst:
(I also updated that notification_print() so it uses LOG_* and less lines overall because too many lines = log just scrolls at light speed and I cannot really read it 😆) |
Okay, got first version here: https://github.com/xoores/dunst/tree/feature-advanced-scripting This version can override several fields: urgency, icon_path, stack_tags, category, format, body, summary, progress, transient and timeout. It uses some bash incantations to acheve this, mmap to move data around and some pointer-based parsing. I tried to document as much as possible to make it easier to understand what I was going for. If script returns anything else than 0, the notification is thrown away. If one script returns non-zero status, no other scripts are run. This is for debate, someone might want to use this as e.g. way to push notifications to Slack or something and it this scenario it would be of course bad. If script fails to run or if script outputs too much, it will be ignored (warn will be printed). Meaning no changes will be made to the notification - playing it safe here 🙂 I run this version and I use it to change some fields like this: #!/bin/bash
if [[ "${DUNST_BODY}" == *mattermost.xxx.yy* ]]; then
DUNST_BODY="$(echo "${DUNST_BODY}" | sed -e 's|<a[^@]*||g' -e 's|\(@[^:]*:\)|<b>\1</b>|g' | xargs)"
fi Notes:
I also changed the following:
Questions:
|
Thank you for posting your branch. I think it's best if you made a pull request for it, so I can more easily comment on it. I do have some initial feedback. Please keep unrelated changes out as much as possible, since I do have some comments on them, which slow down the merging on the actual changes you wanted to make. If you want you can make a separate issue or PR for that. |
Created 🙂 Yeah, the #879 is also something I want to tackle as I'd really like to be able to switch worskpaces 😁 Also don't worry about unrelated changes, we can definitely discuss them or outright reject them - some of these were done for ease of debugging and for me to understand the code quicker 🙂 |
Is it possible to interrupt a notification via bash script, which isnt possible due to limited config functionality ?
like I want a app1 notification to be displayed only if app2 is running in background currently ?
The text was updated successfully, but these errors were encountered: