Created attachment 153406 [details] Reference for a simple indicator of unread notifications SUMMARY Basically this is alternative request for the #460760 (https://bugs.kde.org/show_bug.cgi?id=460760). That report was closed because it had idea for a hack with unpredictable consequences. Developers and users clearly won't be happy with buggy numbers on badges ("-1". "0") etc. This one is much simpler and doesn't look that much different from sound markers, volume controls etc on application icons or previews so I hope developers will consider this option. As we all know currently there's only one proper universal API for notification badge - Unity API. KDE Plasma supports it but most applications doesn't and most probably never will for multiple reasons. So with default "Icons-Only Task Manager", user which was away for some time could easily miss that application had some updates (chat message, email etc). Having used "RocketBar" GNOME extension* for some time I realized that It's not that important to have a number of unread messages (535 messages from social network groups or 150 unread emails). But simple red indicator/badge on top of an application icon could be enough to get the user's attention to the program. Some would actually prefer it over badges with numbers as it looks much cleaner. I've attached screenshot with comparison of RocketBar* implementation and classic badges. KDE Plasma clearly knows which application generated notification and when that notification has been read. So I hope implementation of this won't be very hard. STEPS TO REPRODUCE 1. Receive a notification about new message at any messaging application that doesn't support UnityAPI ("Thunderbird", "Google Chat", Viber, Skype, Electron chat apps etc) 2. Check if application icon at "Icons-only Taskbar has an "unread notification" badge OBSERVED RESULT Application icon doesn't inform about new messages EXPECTED RESULT Application icon has a badge with an unread messages counter * https://github.com/linux-is-awesome/gnome_extension_rocketbar
This has exactly the same problem that I brought up in the Bug 460760: the proposal is a hack that requires Plasma to respond to unpredictable application changes. Some apps use system notifications, some don't. Some update their own counts dynamically, some don't. The correct thing is for apps to implement the existing API. For those that haven't yet, then someone should submit patches to do so. It's not rocket science. :) I can understand how it's frustrating to have to use apps that weren't coded properly and don't use the API that was made specifically for this, but someone just needs to fix that.
(In reply to Nate Graham from comment #1) Thanks for the explanation. If you don't mind I still have a few questions :) > Some apps use system notifications, some don't. That's true (e.g. Viber) and naturally they don't show-up at the notification history > Some update their own counts dynamically, some don't. I'm not sure but looks like that's a problem for https://bugs.kde.org/show_bug.cgi?id=460785 as well. I didn't inspect how RocketBar deal with this. Possible workaround is to remove badge when user switch to the application window. Thanks in advance!
> Possible workaround is to remove badge when user switch to the application window. That occurred to me too, but it's quite possible to switch to an app window without actually reading all the unread things. For example, a chat client with 8 unread chatrooms. If simply switching to the window cleared the badge on the Task Manager button, this would make the Task Manager button inconsistent with the actual status, which is that you still have 8 unread chats. This is why we need apps to opt into using the correct API for this. If we try to approximate it ourselves, we'll be chasing down edge case bugs like this forever, some of which are not actually solvable.