[plasmashell] [Bug 416294] Setting a numeric OSD label outside range 0-100 breaks OSD progressbar

[bugzilla_noreply at kde.org]

https://bugs.kde.org/show_bug.cgi?id=416294

--- Comment #5 from i.hin.hurin at gmail.com ---
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!)

-- 
You are receiving this mail because:
You are the assignee for the bug.