I'm using xchat for my work on opensource, giving instant feedback is one of my priorities,currently I can not set up KDE to blink taskbar when there is a new message in xchat that needs my attention, this way I miss a lot of user questions, I would prefer to get an option to configure the blinking - I understand most users prefer to be not disturbed by new messages, I actually need this feature to do my task right. Reproducible: Always Steps to Reproduce: 1. open xchat 2. configure notifications in taskbar 3. wait for it, the taskbar gets static frame, it is not enough to get my attention, I consider it as a bug.
Implementation notice: If this were to be implemented the animation tick should be global, to make sure concurrent notifications on multiple task buttons run in lockstep.
I know the Visual design team has to decide it, but what about changing the color of the blue bar to red if it needs attention. or Blue = everything is fine Yellow = Attention needed Red = Error
> I know the Visual design team has to decide it, but what about changing the color of the blue bar to red if it needs attention. That already happens. This report is about animation.
(In reply to comment #3) > > I know the Visual design team has to decide it, but what about changing the color of the blue bar to red if it needs attention. > > That already happens. This report is about animation. ok, you are right, just tested it. Anyway color blind people will have a hard time without animations, so I agree we need something that shows that the window needs attention in form of a small graphical element and/or animation
After some research, in all cases of color blindness I've been able to identify, the color used for tasks that require attention in the Breeze theme provides sufficient contrast to other colors to allow distinguishing that task from others on the taskbar. A simple animation like a 1 sec pulsing of attention frame opacity should be fine. But if it is decided to do thisl, I don't think it need be driven be color blindness concerns.
So can we maybe close the bug? Or maybe we just want to have a blind-friendly theme?
Well it's a wishlist item, closing it would require committing to "we don't want to grant that wish".
well.... I've been waiting for the big pumpkin carriage, but I never seem to get it... ;) As far as I can see, Michal considers Breeze should look different than it does, so we need to decide whether it has to blink or not.
Well but it's not just a theming thing - Breeze currently *can't* blink, since the code using the theme elements doesn't have blinking support. Ultimately it comes down to personal beliefs about just how attention-grabbing a task seeking attention should be. For example, personally I'd be annoyed by the blinking, since I do want to be able to see the attention-grabbers when I look there, but not for them to distract me when I don't look there. For others this is too inconspicuous: They don't want to miss the notifications. It's unclear how this can be solved for all people.
So we should bring it to the mailing list? Should we let the themes specify if this blinks?
Theming isn't a good/complete solution because our theme chooser provides no indication whether the Task element will bink, nor is having blinking and non-blinking versions of themes a good idea. We have three options: a) Say no. Done. b) Say yes and unconditionally blink. c) Say yes and also add an option in the widget's config. 'b' and 'c' rely on support for animated blends between prefixes in FrameSvgItem; I'm definitely not going to hack it into the delegate (bad visual results, much overhead, etc.). This was already on the todo for the component anyway, and has a technical proof of concept now in the new impl of IconItem which does animated blends via QSG. I rule out 'b'. My personal preference is 'a'. That leaves mustering time and energy for 'c' depending on feedback, and clearing the tech requirements.
From the visual design side, no objection to Eike's preference. For all the reasons Eike mentioned I'm not excited about blinking as an attention getting mechanism.
Thanks Andrew, then I'd say let's close this for now and wait on / keep an eye out for more user feedback.