SUMMARY When using the mouse wheel to change the volume through the Audio Volume applet, if the wheel is scrolled with the mouse cursor positioned over the applet's tray icon, then any custom "Volume step" value configured by the user in the applet's settings is respected; but if the wheel is scrolled with the mouse cursor positioned over the volume bar of a specific audio device or application within the applet's main screen, then the custom "Volume step" is not respected and a default step of 6% is used instead. STEPS TO REPRODUCE 1. Right-click on the Audio Volume applet's tray icon -> Configure Audio Volume... 2. Change the default "Volume step" value to something arbitrary, let's say 10%. 3. Position the mouse cursor over the Audio Volume applet's tray icon and scroll the mouse wheel up and down: the volume changes as expected, i.e. it goes up and down in steps of 10%. 4. Click on the Audio Volume applet's tray icon to open the applet's main screen; move the mouse cursor so it is positioned over the volume bar of an audio device or an application currently playing audio; scroll to change the volume of only that specific device/application. OBSERVED RESULT The volume is changed in steps of the default 6%. EXPECTED RESULT The volume should have changed in steps of 10%, as per the "Volume step" value configured in the applet's settings. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.16.2 (but it's been working like this since forever) KDE Frameworks Version: 5.59 (...same) Qt Version: 5.12.4 (...same) ADDITIONAL INFORMATION I believe the problem is that the "Volume step" value in the applet's settings is set to only apply to the system's "overall" volume; so when the system's overall volume is changed by scrolling over the applet's tray icon, it is indirectly applied to the "default" audio device and everything works properly; but when the volume is changed directly for either the "default" audio device itself or for any other specific device and/or application, then the custom "Volume step" value is never even considered and thus the default value ends up always being used.
Nor default 5% volume step is respected when scrolling directly over the entry of an audio device or application. Here volume increases/decreases 8%. Operating System: Arch Linux KDE Plasma Version: 5.18.0 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1
Same, except here it changes by 6%.
Created attachment 126048 [details] Patch As this tracks attention, I will post the patch here. Unfortunately there is a bug that prevents from applying. https://bugreports.qt.io/browse/QTBUG-76136 This prevents finer volume setting while dragging with mouse on slider.(It will snap based on volume step.) Proper function with PC2 cannot achieved, there is a limitation in QQC1 of max 20 steps. Currently there is not any effective step. This means minimum step is 6 or 8 when max volume is raised. If a smaller step is set, will jump to the next step. E.g. If set 5, will jump every 10.
It's now plasma 5.21.3 and frameworks 5.80.0, and this still behaves as erratically as before, with the difference that now the default step is 1% instead of the originally reported 6%. Also, sometimes the volume step changes from 1% to 2%, leading me to believe there is also a rounding error somewhere in there. Perhaps the values returned from Pulseaudio are floats? I should also mention that I've switched my system from Pulseaudio to Pipewire+Pulseuadio emulation, so that could be the reason why this bug has altered its behavior. And by the way, provided the rounding error (?) is resolved, I now actually find it useful that I can change the volume of a device/app by a different amount when tinkering directly with its volume bar: e.g. 5% or even 10% per step for quick system volume changes, and 1% per step for "surgical" manipulation of a specific device/app; but I'd still like that to be a configurable and officially documented behavior.
(In reply to gvgeo from comment #3) > Created attachment 126048 [details] > Patch > > As this tracks attention, I will post the patch here. Unfortunately there is > a bug that prevents from applying. > https://bugreports.qt.io/browse/QTBUG-76136 This prevents finer volume > setting while dragging with mouse on slider.(It will snap based on volume > step.) > > Proper function with PC2 cannot achieved, there is a limitation in QQC1 of > max 20 steps. > Currently there is not any effective step. This means minimum step is 6 or 8 > when max volume is raised. If a smaller step is set, will jump to the next > step. E.g. If set 5, will jump every 10. That bug in upstream Qt was fixed early this year. Can the patch be applied now?
(In reply to Decius Matho from comment #5) > > That bug in upstream Qt was fixed early this year. Can the patch be applied > now? I do not use it now days, so I cannot test it or patch it. But for anyone interesting to make a patch should be very easy. From what I can tell looking the code https://invent.kde.org/plasma/plasma-pa/-/blob/master/applet/contents/ui/ListItemBase.qml only need to replace stepSize and add snapMode. stepSize: volumeStep snapMode: Slider.NoSnap Hopefully it works and does not break any functionality.
I do believe that having separate step sizes for the volume up/volume down keys and scrolling is nice. With scrolling, it is very easy to scroll continuously, so a smaller step size is desirable. But with hot keys, we might want a bigger step size. Exposing both values as configuration options is probably an overkill though. Overall I am quite happy with the current status -- with scrolling the default of 1% is used, and with hotkeys users can configure the step size. I would vote for closing this as intentional.
(In reply to fanzhuyifan from comment #7) > I do believe that having separate step sizes for the volume up/volume down > keys and scrolling is nice. With scrolling, it is very easy to scroll > continuously, so a smaller step size is desirable. But with hot keys, we > might want a bigger step size. > > Exposing both values as configuration options is probably an overkill > though. Overall I am quite happy with the current status -- with scrolling > the default of 1% is used, and with hotkeys users can configure the step > size. I would vote for closing this as intentional. This issue here though is not a disparity between using keyboard shortcuts and scrolling with the mouse, but a disparity between scrolling in one section of the UI and scrolling in a different section of the UI, both sections supposedly serving the exact same purpose/functionality, i.e. increasing/decreasing the volume by scrolling the mouse cursor over a slider. Scrolling behavior should be either uniform or configurable, and in any case absolutely predictable by the average non-technical user. Intentionally keeping this undocumented and non-configurable behavior would be a criminal thing to do UX-wise, and I'm saying that as someone who has grown used to this behavior and even finds it useful for some tasks.
Git commit 661f40d7a4f81fd0aebf67c09a9dd5ea17b6fb1f by Yifan Zhu. Committed on 24/01/2024 at 19:00. Pushed by fanzhuyifan into branch 'master'. kcm/VolumeSlider: fix scroll stepSize was not set to disable tickmarks. However scrolling also depends on stepSize. qqc2-desktop-stlye implements scrolling via increase()/descrease() functions, which default to steps of 0.1 when stepSize is not set. Override them to get scrolling working without setting stepSize. Related: bug 459639 FIXED-IN: 6.0 M +6 -2 src/kcm/ui/VolumeSlider.qml https://invent.kde.org/plasma/plasma-pa/-/commit/661f40d7a4f81fd0aebf67c09a9dd5ea17b6fb1f
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/235
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/236
Git commit ec336f6451e92b8946eb750068ebe31875a2fd4e by Yifan Zhu. Committed on 24/01/2024 at 19:14. Pushed by fanzhuyifan into branch 'Plasma/6.0'. kcm/VolumeSlider: fix scroll stepSize was not set to disable tickmarks. However scrolling also depends on stepSize. qqc2-desktop-stlye implements scrolling via increase()/descrease() functions, which default to steps of 0.1 when stepSize is not set. Override them to get scrolling working without setting stepSize. Related: bug 459639 FIXED-IN: 6.0 (cherry picked from commit 661f40d7a4f81fd0aebf67c09a9dd5ea17b6fb1f) M +6 -2 src/kcm/ui/VolumeSlider.qml https://invent.kde.org/plasma/plasma-pa/-/commit/ec336f6451e92b8946eb750068ebe31875a2fd4e
Git commit 7d052ac30f50656a3545d0ef7376346943254c2c by Yifan Zhu. Committed on 25/01/2024 at 04:29. Pushed by fanzhuyifan into branch 'master'. applet: respect volumeStep setting in slider Also uses the global config object as SSOT. FIXED-IN: 6.0 M +2 -2 applet/contents/ui/ListItemBase.qml https://invent.kde.org/plasma/plasma-pa/-/commit/7d052ac30f50656a3545d0ef7376346943254c2c
Git commit 0dfd85920d847fa977f1b31a77dc87ff050c3167 by Yifan Zhu. Committed on 25/01/2024 at 04:32. Pushed by fanzhuyifan into branch 'Plasma/6.0'. applet: respect volumeStep setting in slider Also uses the global config object as SSOT. FIXED-IN: 6.0 (cherry picked from commit 7d052ac30f50656a3545d0ef7376346943254c2c) M +2 -2 applet/contents/ui/ListItemBase.qml https://invent.kde.org/plasma/plasma-pa/-/commit/0dfd85920d847fa977f1b31a77dc87ff050c3167
This fix might also fix bug 479879