SUMMARY Passing a numeric value to progressBar component (file org.kde.breeze.desktop/contents/osd/OsdItem.qml, line 66) outside the specified 0-100 min/max range results in the OSD progress bar itself stuck on either 0% or 100% until plasmashell restart. This can happen e.g. when switching default audio output to a bluetooth headset who identifies itself to the system with its own model number (an easy workaround here is changing the headset name to something else, but it's not an obvious fix for the problem). STEPS TO REPRODUCE 1. set an invalid number as osdValue on OsdItem (e.g. set as default audio output a badly named usb device, triggering an OSD notification showing device's name) 2. trigger an OSD notification with a progress bar (e.g. change volume or screen brightness via hotkeys) OBSERVED RESULT OSD progress bar is stuck on 0% or 100% until plasma restart EXPECTED RESULT OSD progressbar showing the right volume/brightness/etc. level SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.65.0 Qt Version: 5.14.0
Can you give steps to reproduce with a list of calls to: qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.brightnessChanged <some number here>
I can't reproduce. I tried various combinations of: qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.showText dialog-information "Some stupid long text which will cause problems" qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.volumeChanged 200 qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.volumeChanged 25 qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.volumeChanged -50
Created attachment 125185 [details] screenshot 1 - bug triggering message
Created attachment 125186 [details] Screenshot 2 - after setting brightness to 50% via qdbus
Sorry, just some bad wording from my part. The issue arises because the notification of the audio output change (see schreenshot 1 - my headphones are unfortunately labeled as "40337" by the bluetooth stack, and I had neved bothered changing that). This string is passed down to this section inside "/usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/osd/OsdItem.qml": PlasmaComponents.ProgressBar { id: progressBar anchors { bottom: parent.bottom left: parent.left right: parent.right margins: Math.floor(units.smallSpacing / 2) } visible: rootItem.showingProgress minimumValue: 0 maximumValue: 100 value: Number(rootItem.osdValue) <======== problem happens here! } This snippet of code smartly hides the progressbar if there is no useful value to display, still passes the actual string tho the highlined line. If rootItem.osdValue happens to be a regular string, PlasmaComponents.ProgressBar works as intended (i think due to Number() passing down some NaN or something like that, I haven't researched), and in fact if I change name to my device (something like "Headphones" instead of "40337"), everything indeed works fine. The bug arises when osdValue actually contains some string that can be parsed as a number (like my unlucky "40337"). In this case, PlasmaComponents.ProgressBar's value gets set to a value outside the intended 0-100 range and triggers the bug (see screenshot 2, taken after running qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.volumeChanged 50). This persists until a plasma restart. As a quick hack I changed that code line to: value: Number(rootItem.osdValue) <= 100 ? Number(rootItem.osdValue) : 0 which in my case solved the issue as well. However, this is not a complete solution (negative numbers still trigger the bug), it's just a crude hack and frankly I don't have the experience to tell if it's actually better to fix this behaviour inside the ProgressBar component. It's a really minor issue, so sorry for the wall of text, but I reported this because it could trigger some hard to investigate bugs (sure this one was for me!)
typo: the command run on screenshot 2 was "qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.brightnessChanged 50", not the volumeChanged one I mistakenly copy-pasted in comment 5 (which shows the exact same problem, btw).
(In reply to Kai Uwe Broulik from comment #2) > I can't reproduce. I tried various combinations of: > > qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.showText > dialog-information "Some stupid long text which will cause problems" > qdbus org.kde.plasmashell /org/kde/osdService > org.kde.osdService.volumeChanged 200 > qdbus org.kde.plasmashell /org/kde/osdService > org.kde.osdService.volumeChanged 25 > qdbus org.kde.plasmashell /org/kde/osdService > org.kde.osdService.volumeChanged -50 No problem with "proper" strings or strings that can be parsed into numbers inside 0-100 range, these two commands don't trigger the bug: qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.showText dialog-information "Some stupid long text which will cause problems" qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.showText dialog-information "50" Steps to reproduce: qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.showText dialog-information "-1" # triggers the bug qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.volumeChanged 25 # progressbar stuck to 0% no matter the number entered # restart plasma here, and everything works again qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.showText dialog-information "101" # triggers the bug qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.volumeChanged 25 # progressbar stuck to 100% no matter the number entered
No longer an issue with the latest OSD design as it can accept higher numbers now