Summary: | Display the number of notifications on the systray instead of the bell when applet is always visible | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Rind <kde.milrind> |
Component: | Notifications | Assignee: | Kai Uwe Broulik <kde> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | nate, plasma-bugs, xalt7x.service |
Priority: | NOR | Keywords: | usability |
Version First Reported In: | 5.20.90 | ||
Target Milestone: | 1.0 | ||
Platform: | Other | ||
OS: | Other | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
example
This number that appears during downloads and file copies is a good example. I'm not a developer but I think it's already something "ready" for everything else? |
Description
Rind
2021-01-24 17:00:10 UTC
Created attachment 135134 [details]
example
Created attachment 135144 [details]
This number that appears during downloads and file copies is a good example. I'm not a developer but I think it's already something "ready" for everything else?
The use case of having the notification applet set to always visible seems valid. We removed the number with the expectation that the user would have it set to auto-hide. Having it always visible would indeed seem to benefit from seeing the number of unread notifications rather than the bell. thank you for considering this If you find a way to align a number in a circle/badge so it doesn't look horrible, I'm fine with adding the number back. What I quoted in the previous comment cannot be reused? I switched back to using the option to display the icon only when relevant for a few minutes and I think I can suggest another solution for that. When there are pending notifications, the icon is displayed, great, but when they accumulate and I need to access the icon more than once it is not possible. Because the icon is hidden the first time it is clicked, even if there are still other pending notifications. So an option to only hide the icon if all notifications are cleared/deleted would be a good work-around for this. Since this is a different way of handling this problem than suggested in this bug report, I may create another different report. *** Bug 460785 has been marked as a duplicate of this bug. *** |