SUMMARY Not sure since which version, but now notification doesn't popup up again when being replaced. STEPS TO REPRODUCE previous=`notify-send -p -t 4000 TEST TEST` ; sleep 5; notify-send -r $previous -t 4000 TESTA TESTB OBSERVED RESULT TESTA / TESTB doesn't show up EXPECTED RESULT after timeout, while the notification is still in history, the new replace will be able to make it popup so user can see it. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.20.0 Qt Version: 6.10.1
Can reproduce.
I think this is technically a violation of notifications spec. You are not supposed to use again id of expired or dismissed notification. Though we already show notification again if was replaced after being dismissed, it wouldn't be hard to do the same for expired ones.
Now I wonder, should we show two entries in history if user lets this second notification expire too? I.e. should it act as a new notification or not? There may be trouble with notification ids. We keep track of notifications by their ids, and that includes notifications in history too. So if we want to show this new notification separately then it must have a different id. However we can't do that because notifications spec says that Notify method returns replaces_id if it wasn't zero.
(In reply to equeim from comment #3) > Now I wonder, should we show two entries in history if user lets this second > notification expire too? I.e. should it act as a new notification or not? > > There may be trouble with notification ids. We keep track of notifications > by their ids, and that includes notifications in history too. So if we want > to show this new notification separately then it must have a different id. > However we can't do that because notifications spec says that Notify method > returns replaces_id if it wasn't zero. Maybe we should just return an error over D-Bus in such cases? The spec says that you should do so in CloseNotification if it doesn't exist but we don't do that either. It says nothing what to do if replaces_id refers to non-existent notification. Looking through GNOME's source code it seems that's what they do.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6168
This is intentional.