https://bugs.kde.org/show_bug.cgi?id=407536
--- Comment #8 from Nate Graham ---
Other ideas for communicating this to the user better:
- Make persistent notifications look visually distinct somehow
- Tweak the wording in the KCM to emphasize that the timeout only applies to
non-persistent notific
https://bugs.kde.org/show_bug.cgi?id=407536
Nate Graham changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=407536
--- Comment #6 from David Edmundson ---
>or the condition that's being notified about is no longer applicable.
>From a notification POV that's exactly what is happening.
When we delete an applet it doesn't actually delete it, in case a user hits
undo
https://bugs.kde.org/show_bug.cgi?id=407536
--- Comment #5 from Nate Graham ---
My mental model of how a persistent notification works is that it lasts until
either the user manually dismisses it, or the condition that's being notified
about is no longer applicable. If this isn't the case, it's a
https://bugs.kde.org/show_bug.cgi?id=407536
--- Comment #4 from David Edmundson ---
Undo lasts 60 seconds. It can't last forever.
The popuo is persistent while the notification is active.
I don't see what's wrong there or what you could do differently.
--
You are receiving this mail because:
Y
https://bugs.kde.org/show_bug.cgi?id=407536
--- Comment #3 from Nate Graham ---
Rather, a client should only delete its own persistent notifications after they
no longer apply, not based on an arbitrary time limit.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=407536
Nate Graham changed:
What|Removed |Added
CC||n...@kde.org
--- Comment #2 from Nate Graham ---
https://bugs.kde.org/show_bug.cgi?id=407536
David Edmundson changed:
What|Removed |Added
CC||k...@davidedmundson.co.uk
--- Comment #1 from
