After the upgrade to Plasma 6.3.0, I noticed two things: 1. The option to show/hide audio indicators in the Icons-Only Task Manager has been renamed to "Use audio indicators to mute task" (if I remember it correctly, it was "Mark applications that play audio" or something similar). The new setting name is fine; however, I had it previously turned OFF (personal preference), but it was turned ON after this update (previous preference was not preserved). 2. With the new option turned OFF, sometimes it still shows the audio indicator (with a bit of delay). The only difference I can notice with the option turned OFF was that the "playing audio" button wasn't clickable, but that's it. Also, I noticed that in mini-previews (mouse-over on apps in the Icons-Only Task Manager) show the audio control for the hovered window, even with the option "Use audio indicators to mute tasks" disabled. I believe that is also meant to be hidden when this option is disabled. That's all. Thanks. Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.12.11-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland
My suggestion is to have two options: - Show audio indicators - Use audio indicators to mute task
*tasks
I don't see a benefit in having two options. How could that be useful? I believe that, if the icon is visible, then it can have the function of muting the audio by consequence.
The user may want to see which apps are playing sound, yet not want to disable it from the task manager, as they may accidentally click the icon. If you ask me, I will use neither option. I don't need that icon at all.
>but it was turned ON after this update (previous preference was not preserved). That's expected, the original setting is removed, this is a different thing. >The only difference I can notice with the option turned OFF was that the "playing audio" button wasn't clickable, but that's it. that's the intended behaviour of the MR which changed this. You're not alone in wanting different behaviour, lets follow on that other ticket. *** This bug has been marked as a duplicate of bug 499891 ***