In bug #342260 Edmundson says: > In Plasma 5.x it was changed so they only appear in the backlog if the notification is persistent (i.e if the timeout == 0") That's "-t 0" on notify-send. That is reasonable behaviour, I suppose. However, I believe there are user scenarios where it is extremely useful to remember non-persistent notifications. An example of such would be a long operation (e.g., copying a large file) running unattended. Reproducible: Always Steps to Reproduce: 1. Pick a large file, or a slow disk, or a remote host on a 9600 baud modem. Any combination that'll take a while. 2. Launch a copy or move operation, e.g., from Dolphin. 3. Go away for a while. 4. Come back. 5. Wonder what happened to your operation. Did it complete? Fail? Something else? Actual Results: If the notification was non-persistent, as Dolphin's is, it will have disappeared from screen and never gone into the history. You will not know how it did. Expected Results: A configurable setting in the notifications widget should allow the user to force notifications to persist. It is reasonable that a notification for certain “routine” operations should be made non-persistent by the developer, however in certain scenarios that may not be in line with the user's wishes.
*** This bug has been marked as a duplicate of bug 353423 ***
...as for the operation notification, that is stored. It was a bug somewhere between 5.5.0 and 5.5.3 that it wasn't, but it's fixed now.
(In reply to Martin Klapetek from comment #2) > ...as for the operation notification, that is stored. Can you please clarify? I do not understand what you are referring to.
Also, aside from bug 353423, there is bug 357750 and bug 342260 (and of course, this one). If I understand correctly what it all boils down to, you maintain that status notifiers should be used in those cases where notifications are currently used. You may well be right that your idea would be more in the spirit of how the respective specs (notifications, status notifier) were written. However, real-world usage has evolved in a different direction, which has worked with no particular problems that I am aware of up to this day. So it may well be that the specification is wrong / no longer relevant / in need of review. Or simply, that your particular interpretation is just one amongst many, and not necessarily the majority's. Either way, could you please point me to the notifier sources? I'll just patch it my own copy of it.
> Can you please clarify? I do not understand what you are referring to. To this: > An example of such would be a long operation (e.g., copying a large file) running unattended. --- > could you please point me to the notifier sources? Now I don't understand what you're referring to. Can you please clarify?
(In reply to Martin Klapetek from comment #5) > > could you please point me to the notifier sources? > > Now I don't understand what you're referring to. Can you please clarify? Where is the source code for the notifier, so I can patch it myself? I got as far as here: https://projects.kde.org/projects/kde/kde-workspace/repository then I get lost.
"Notifier" is the application that notifies. If you want the notification server and applet, that would be in plasma-workspace/dataengines/notifications and plasma-workspace/applets/notifications respectively.
Yup just found it, cheers.