-
Notifications
You must be signed in to change notification settings - Fork 336
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
Get the history stack from command line #307
Comments
Please, help! How to get history? I lost important notification! |
@11111000000 If more than 20 notifications have been sent since it's not possible unfortunately. The history_length setting controls how many notifications are kept in history, and it's set to 20 by default. History is never saved anywhere, it's just in memory while dunst is running because it's not meant to handle important data it's there as a "I need a way to see what I missed". |
Just a note because I see this thread pops on google when you search for dunst history. You can run |
If that is the case, isn't this issue a candidat for closing? |
I didn't make the original issue and it makes a slightly different request, looking for the data, rather than replaying the notification. I just added it in case people run into a similar need. |
The man page also erroneously calls out
|
Managed to implement it however it has REALLY ugly output. Especially because of unbroken newlines messing with the output. Posting code soon... |
The current implementation tries to retrieve notifications stored in the history buffer (which means they've been either discarded or hidden by the user) and does so using the existing D-Bus system. However the output of the dbus-send command is (in my opinion) super ugly and unusable for any practical scripting application. This is VERY much still a work in progress.
* dbus/dunstctl: add history command (#307) The current implementation tries to retrieve notifications stored in the history buffer (which means they've been either discarded or hidden by the user) and does so using the existing D-Bus system. The output format is JSON, so it can be easily processed by scripts. * dbus: check string validity before sending reply * dbus/dunstctl: use dictionaries instead * dbus: change whitespace to blank string * dbus: change history callback function name * dbus/dunstctl: add history-pop-id functionality (#970) * contrib: add notification-history.sh (#970) * dbus/dunstctl: change i32 to u32 for history-pop-id * queues_history_pop_by_id: remove old notification from history when restore (bug) * test/queues: add notification_skip_display_redisplayed_by_random_id * test: add queue_get_history * dunstctl: history-pop-id change to uint
…#970) * dbus/dunstctl: add history command (dunst-project#307) The current implementation tries to retrieve notifications stored in the history buffer (which means they've been either discarded or hidden by the user) and does so using the existing D-Bus system. The output format is JSON, so it can be easily processed by scripts. * dbus: check string validity before sending reply * dbus/dunstctl: use dictionaries instead * dbus: change whitespace to blank string * dbus: change history callback function name * dbus/dunstctl: add history-pop-id functionality (dunst-project#970) * contrib: add notification-history.sh (dunst-project#970) * dbus/dunstctl: change i32 to u32 for history-pop-id * queues_history_pop_by_id: remove old notification from history when restore (bug) * test/queues: add notification_skip_display_redisplayed_by_random_id * test: add queue_get_history * dunstctl: history-pop-id change to uint
I'm pleased to say that the history command has been added. This issue can be closed :) |
Let the users get notification history with something like
dunstcli --get-history
ordunstcli ls
and then leave it to them to do with the data whatever they want.One use case that I have in mind specifically is displaying notification count in the panel, as well as some other info based on what kind of notifications are in the history stack at the moment.
This feature request belongs to the general idea of exposing functionality to the command line: #284
The text was updated successfully, but these errors were encountered: