Feature: remove_current in notification queues

[FelipeFTN]

Pull Request Purpose 🤔

This pull request introduces a new "remove_current" mouse action to allow users to remove notifications from history; implementing its functionality in the notification handling logic, and updating tests and documentation. 🚀

I really love the dunst project, and I think a very basic and useful feature that it's currently missing is to click and remove the notification from history.
So I decided to implement it! 🎉

Here's my quick contribution to the project ❤️
The main ideia, is to have "do_action" and "remove_notification" to work together nicelly, and avoid stuff like this:

A history with a lot of already read/clicked notifications

I hope the Pull Request goes well and the code is not that mess hahaha
This PR was highly inspired by #1463 🚀

I hope it works and get merged soon for other users to also use this amazing feature! 🙏

PS: I also updated the docs to include this new option/functionality, and added a tiny test suit in the valid_options, nothing big. 👍

Thanks!

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 6.25000% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.80%. Comparing base (fb59a30) to head (064ba98).
⚠️ Report is 8 commits behind head on master.

Files with missing lines	Patch %	Lines
src/queues.c	10.00%	9 Missing ⚠️
src/input.c	0.00%	3 Missing ⚠️
src/menu.c	0.00%	3 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1491      +/-   ##
==========================================
- Coverage   64.90%   64.80%   -0.10%     
==========================================
  Files          51       51              
  Lines        9024     9039      +15     
  Branches     1048     1057       +9     
==========================================
+ Hits         5857     5858       +1     
- Misses       3167     3181      +14     

Flag	Coverage Δ
unittests	64.80% <6.25%> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bynect]

thanks for your contribution. I think that it's best to not change the default values of the config.

Also for the code, instead of making a separate queues_remove... function, why not reuse the existing functions to close and remove history?

[bynect]

let me know what do you think

[FelipeFTN]

Hello, @bynect, Thanks for helping me with this contribution! 🎉

I just read the comments, nice catches! I'll just point some questions here for we to finish this feature as soon as possible!

So, the idea of keeping the dunstrc file as is, is great! I should not have changed the default behavior haha Just thought about it after opening the Pull Request, but really doesn't seems to be a good idea! 😅
I will be reverting remove_current as a default behavior with do_action in the next commit, thx!!

Also, you pointed that, we already have functions to handle close and remove signals.
And in the second commentary you suggested using the already built-in functions for close notification and remove from history. well pointed, but I was thinking about separating the responsibilities of close and history do keep them handling just what they should. With that, in case you modify one of these functions in the future, it doesn't affect the remove_current; that logic I also tried to apply to the remove current signal.

Yes, you're right, the remove_current does a simple close & remove from history. But seems cleaner to keep separated responsibilities (close functions only for close action, remove functions only for removing actions, also, I thought the history removing should be used with the close_all or something).

Please, tell me what you think about this logic I used, and if it's incorrect! 🙏
My main idea is to keep using separated queues, signals and menu logic isolated for remove_current action!

Thanks again for your messages! If you believe it's strictly necessary or better to keep the code using shared functions to achieve this new action (remove_current), just tell me and I will change it right away! ❤️

[bynect]

you are right that the operation in the future could differ from a simple combination of those function. as a compromise what about declaring functions remove_current but using internally those two functions?
so that if we ever need we can change the implementation later on

[FelipeFTN]

Hello, @bynect! The changes are done! Let me know if you have any update. 🙏

[bynect]

code looks good. the ci problem is unrelated. I will try it and merge shortly 👍🏻

[bynect]

thanks