dunsctl history-pop and history-rm doesn't emit a signal?

[qxb3]

Hello! I kinda assume that this actions will emit a events in d-bus but i guess not?

$ dbus-monitor --profile "interface='org.freedesktop.Notifications'"
#type	timestamp	serial	sender	destination	path	interface	member
#					in_reply_to
sig	1707417506.140839	4294967295	org.freedesktop.DBus	:1.73277	/org/freedesktop/DBus	org.freedesktop.DBus	NameAcquired
sig	1707417506.140853	4294967295	org.freedesktop.DBus	:1.73277	/org/freedesktop/DBus	org.freedesktop.DBus	NameLost
mc	1707417511.756545	6	:1.73318	:1.39	/org/freedesktop/Notifications	org.freedesktop.Notifications	GetServerInformation
mc	1707417511.757148	7	:1.73318	:1.39	/org/freedesktop/Notifications	org.freedesktop.Notifications	GetServerInformation
mc	1707417511.757979	8	:1.73318	:1.39	/org/freedesktop/Notifications	org.freedesktop.Notifications	Notify

[fwsmit]

Apparently not. What do you need this signal for? You can already request the entire history from dunst

[bynect]

It is useful when i want to get the updated history when i removed a notification

why wouldn't simply calling dunstctl history work?

[qxb3]

It does work but i want it to get the notification in real time and i want to avoid polling as much as possible

[bynect]

I see now that you keep a listen instance always running on the background and use the other subcommands to update that.
I think that at this point you are better off using normal signals (trap and kill) instead of passing through the dbus route

[fwsmit]

I think DBus is well suited for passing signals. For most other things we already pass a signal via DBus, so this just needs to be added.

[bynect]

I think DBus is well suited for passing signals. For most other things we already pass a signal via DBus, so this just needs to be added.

I'll mark this as a feature

[bynect]

In #1405 I added the signal for history removed and history cleared