https://bugs.kde.org/show_bug.cgi?id=440051
--- Comment #3 from kroot.pa...@gmail.com --- > The spec says "The server must atomically (ie with no flicker or other visual > cues) replace the given notification with this one." I understand that, but I believe they were referring to notifications that were actually _visible_ on the screen. I've looked into other notification daemons, and all of those (as far as I know) assume that if the replaces_id is for an expired notification, the user means to display a new notification altogether. See https://gitlab.gnome.org/Archive/notification-daemon/-/blob/master/src/nd-daemon.c#L205 Here are my doubts: 1. Is there a way to make the notification visible again after it has expired? If so, the user can explicitly use that instead of relying on unspecified behaviour. 2. More generally, what is the need to keep around a notification that has expired, and which has _not_ been marked persistent/resident? If the normal notifications are garbage-collected on expiry, https://invent.kde.org/plasma/plasma-workspace/-/blob/ee822faf1c86844b6bcac8f1c55cc152de2c376e/libnotificationmanager/abstractnotificationsmodel.cpp#L96 would get activated and give the desired behaviour. The reason I would like to have this behaviour, is that it greatly simplifies the client code when they want to display only one notification at any given time. They can simply store the id of the last notif they displayed and use that as replaces_id, without having to keep track of whether the previous notif has timed out or not. And sorry for not replying sooner - didn't get any emails of this thread for some reason. -- You are receiving this mail because: You are watching all bug changes.
