In the Desktop Notification Specification? I read that
If
replaces_idis 0, the return value is a UINT32 that represent the notification. It is unique, and will not be reused unless a MAXINT number of notifications have been generated. An acceptable implementation may just use an incrementing counter for the ID. The returned ID is always greater than zero. Servers must make sure not to return zero as an ID.
However, if I do
kill $(pidof dunst)
to ensure that Dunst¹ it will be started anew on next notification, and then enter
notify-send 'hello' -p
notify-send 'hello' -p
notify-send 'hello' -p -r 5
notify-send 'hello' -p
notify-send 'hello' -p
I get these outputs
2
3
5
4
5
revealing that the id 5 is being reused.
In reality, though, I can see that Dunst is not really replacing the 3rd visual notification (the one I produced with explicit -r 5) with 5th.
So it feels like Dunst, which is the server, is conforming... but notify-send, which is the client, is reporting the wrong IDs?? I mean, shouldn't notify-send be receiving the IDs from Dunst?
I'm assuming that, since I don't see the 5th notification replacing the 3rd, Dunst associated 5 dinstinct IDs to the 5 notifications, such as
2
3
5
4
6
(¹) 1.10.0 (2024-02-19)
Actually, experimenting with a notification server I've implemented, I've just verified that notify-send indeed does return whatever the server is passing to it.
So it must be Dunst that, although correctly avoids replacing notifications for which an ID was explicitly requested with notifications for which the ID was not requested, it probably does not do so via IDs, but via some other internally defined unique identifier.
(Indeed.)