In short: I think that when each notification reaches its timeout, if there is an existing notification in the stack which has not had it's timeout fulfilled, the display should shift back to showing this notification and the notification display should remain open. Justification: Important notifications relating to e-mails/messages from my boss are set to have a timeout of 5000 seconds to ensure that I never miss them. Notifications relating to messages from my personal IM accounts are set to have a low timeout. Now if my boss messages me, I definitely don't want to miss that message, and the large timeout is great it ensure the notification stays on the screen. However then if a friend messages me the short timeout on his notification causes the notification display to vanish hiding the fact my boss messaged me. If only the display would respect the timeout of all notifications shown (since it was last closed) that would be much better I think! Reproducible: Always Steps to Reproduce: 1. Issue notification with timeout of 1000 seconds 2. Wait 1 second 3. Issue notification with timeout of 1 second 4. Wait 1 second Actual Results: Notification disappears 1 second after second notification appears. Expected Results: After 1 second the notification with a timeout of 1000 seconds should be displayed (for the next 997 seconds).
I'd like to submit a patch to fix this myself if you guys would be so kind as to review and accept my code. Thank you!
Couldn't get the build system to work in a reasonable amount of time (cmake error messages about strigi include directory) gonna give up on this. Good luck!
Created attachment 78874 [details] Shell script displaying issue.
Worked around my build system issue, almost finished a patch against master/4.10 branches.
Created attachment 78876 [details] Patch to fix issue (using git format-patch) This patch fixes the issue for me, done a bunch of testing. I removed the upper limit you had set of 60 seconds per notification timeout (but kept the lower limit of 4 seconds) as I feel that there are many people who desire to have a higher limit than 60 seconds.
Created attachment 78877 [details] Improved test.
Created attachment 78878 [details] Test showing it accounts for multiple layers of timeout.
Created attachment 78879 [details] Patch for issue (fix whitespace issue with previous patch)
Created attachment 78880 [details] Patch to fix issue - one more whitespace issue + small cleanup Sorry last one I hope!
Created attachment 78881 [details] Patch to fix issue - simplified timer re-arming.
Created attachment 78882 [details] Patch to fix issue - remove unneeded Timer.restart call
If this is your final version of the patch, could you please create a review request for group "plasma" on https://git.reviewboard.kde.org/ Developers do not comment on patches added to bugzilla, unless they are trivial one-liners.
https://git.reviewboard.kde.org/r/110122/
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham