| Summary: | Changing volume via mouse wheel does not respect custom "Volume step" value when scrolling directly over the entry of an audio device or application | ||
|---|---|---|---|
| Product: | [Plasma] plasma-pa | Reporter: | Alexander M. <apmichalopoulos> |
| Component: | applet | Assignee: | David Rosca <nowrep> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | antti.savo, bugseforuns, fanzhuyifan, Gvgeo, matejm98mthw, nate, nbiswhdk, plasma-bugs |
| Priority: | NOR | Keywords: | usability |
| Version: | 5.21.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-pa/-/commit/0dfd85920d847fa977f1b31a77dc87ff050c3167 | Version Fixed In: | 6.0 |
| Sentry Crash Report: | |||
| Attachments: | Patch | ||
|
Description
Alexander M.
2019-06-30 07:24:18 UTC
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 |