Konversation can be configured to use the system tray for new message notifications. If the preference is set, the Konversation icon in the system tray switches each second from monochrome to red, or back to monochrome. This feature is very useful to avoid missing messages. Unfortunately, it is also very stressful, both for the user and the computer. As a user, having the icon change each second is very distracting. If you're busy doing something more prioritary, it can be distracting for a while unless you resign to flush the notification. This wouldn't be so bad if notifications appeared once in a while, but if you're manning a busy support channel, this can be a significant source of frustration or waste of time. In channels with hundreds of users, a conversation in which you don't want to intervene will frequently start and generate several notifications each minute, which will either require lots of efforts to dismiss, or be quite irritating until you estimate that the discussion is over and proceed to flush the notifications. As a computer, it's quite CPU-expensive to change the icon each second. This is very visible in the CPU usage of Xorg, plasma-desktop and kwin. I've collected the following data during 2 nights, one during which I left Konversation open and one during which I closed it. In 9 hours 52 minutes of idling without Konversation, kwin took 3 seconds, plasma-desktop 31 and Xorg 8. In 13 hours and 55 minutes of idling after Konversation started notifying of a new message, kwin took 19:06, plasma-desktop 37:25 and Xorg 22:23. In other words, when you're idling with systray notifications enabled on a major channel, Konversation will roughly cost you 1 hour of CPU usage for 10 hours of idling (this was measured on a recent quad-core AMD APU (A10-5700)). On my previous PC (a 2009 laptop), I could often tell there was a new message just from the fan's noise. Multiple improvements could alleviate these issues. A simple one would be to stop computing icon changes when the icon is not displayed (because the screen is saving power, for example). If that's not possible, I suggest a single change which would have a big effect on both stresses... Initially, the systray icon's behavior is fair. However, after a few minutes, changing each second becomes excessive, for 2 reasons: If you didn't act on the notification before, you're less likely to act on it quickly It's statiscally less urgent to see the message after a while. The user who asked may have left, have been answered by someone else, or by himself. If you were the one asking, you may have worked around already. Therefore, I propose to simply progressively increase the time taken to change Konversation's icon. I suggest a simple pattern - a linear increase. Switch after 1 second, then 2, 3, etc. This could mean switches would already be 10 seconds apart after 50 seconds. A simple implementation could have one drawback - it may take a lot more time to notice a new message after you wake up if the icon only changes after 30 seconds. This could be avoided by adding a sign to the icon when there's a notification, or very cheaply by keeping the icon red almost all the time (make the icon red immediately, then monochrome after 1 second, red 1 second later, monochrome 2 seconds later, red 1 second later, monochrome 3 seconds later...). There is one annoying complication which arises when Konversation is notifying about multiple messages. Once there is a first new message, should further new messages reset the interval to 1 second? The 2 goals conflict here. If it was just about saving energy, the interval would keep growing, but if the primary goal is to avoid unnecessarily stressing the user, the interval should reset. For what it's worth, Kopete's systray icon also reflects whether you got a new instant message. This one never annoyed me nearly as much since I receive a lot more messages via IRC than via IM, but the animation suggests it must be even more CPU-expensive, and the considerations are the same.
There are good ideas here, however they're actually at least partially directed at the wrong product. In the modern status notifier item protocol, the visualization is entirely left to the shell. With the old X11Embed-based tray protocol we computed the blink pattern ourselves for example; nowadays, we just inform the desktop shell that our notifier item is considered "active" and it decides how it wants to blink. This makes it difficult to impossible for us to affect behavior in a way more tailored to the application.
Thank you Eike. I was unaware of that situation, that's unfortunate in a sense. So from what I can see, the options are: Go back to old but more flexible protocol. Costly Push for changes to the current protocol. Presumably even more costly, but would other projects benefit too? Kopete, KMail, Akregator? Disable updates when the tray icon is not displaying. Only addresses the CPU stress issue, but does that even more than my suggestion. Cost?
The "don't blink stuff when the screen is off" thing shouldn't be hard to implement in Plasma Desktop at least ...
When "Use system tray for new message notification" is used, the CPU usage of plasmashell is insane high. I'm using: Konversation 1.6 KDE Frameworks 5.13.0 Qt 5.4.2 (built against 5.4.2) The xcb windowing system
Since this is still open, I comment here instead of opening a new report. I just experienced this. When Konvi shows the notification in systray, I get 20% cpu load for the kwin process. The only difference I see to this report is that my notification icon animates with insane speed. I read about an issue like that with nvidia GPUs but I have a built-in Intel thingy. I also read about this being a problem when running the monitor on high refresh rates. Mine however runs at 60Hz. It's a bit hard to tell for me what the cause is but Konvi is the only application showing that behaviour. Copy spinners and loading icons as described in some other reports are fine here.