Mouse-wheel control
Posted: 25 Mar 2020 23:10
The setup of how the scroll wheel/buttons on the mouse work to manipulate the volume or playback position needs some additional options.
The options of "inverted" or "reversed" needs to be added for all scenarios.
It has become an increasingly standard feature to be able to switch the scrolling axis with a modifier key or button. But there are varying scenarios and logic for how the user expects that to work. While it is fairly well accepted that scrolling up takes you to the top of the page, there is less-defined consensus on whether scrolling UP should increase or decrease the elapsed time/playback position if the axis has been switched by a key or button.
The user should be able to configure separately for each axis how the volume and playback position are affected by the scroll wheel.
Another complication arised when scrolling is setup as "natural" — (to many this may seem to be anything but natural, but if you imagine that the movement of the finger flicking up is pushing up an underlying piece of paper in order to see what is at the bottom of the page, the logic becomes more clear). However, this becomes very counter intuitive when controlling the volume in VLC because now flicking up LOWERS the volume (because it is technically scrolling down)!
Another prime example is a trackball which either has an outer rotating ring for scrolling or one simply turns the ball on the same axis as a ring or a knob for scrolling. This can create extremely counter-intuitive situations, especially when the same rotation can represent either vertical or horizontal scrolling with the press of another mouse button or modifier key(s).
We do not have any standardized, well-established or deep-rooted history of using knobs to manipulate movement of the content on a screen/display/monitor; therefore, it is a matter of personal preference whether one chooses clockwise or counterclockwise rotation to scroll up or down — it is likely to be dependent upon the movement/gesture the user employs to manipulate the wheel (are they using a finger to move the top of the ring to the right, or their thumb to move the bottom of the ring to the left to generate clockwise rotation of the ring?).
However, knobs which rotate on this axis have a long history of standardized use to control increments and decrements of volume, for example, and I've never encountered technology with knobs which didn't conform to the behavior of clockwise representing increase. Without the ability to choose separately for each scrolling axis how playback/volume is affected in VLC we end up with some very counter-intuitive situations which are not solvable using any methods available to standard end-users such as the config software for these devices or the system control panels/settings.
Consider this scenario: a trackball with a rotating outer ring for scrolling. Clockwise rotation is configured for scrolling down. But, over a playing video in VLC this turns the volume down instead of up. And how is the position affected if the rotating ring is switched to horizontal scrolling? And as I described above, whether or not that makes sense to the user will depend on how that rotation is generated by their hand.
In many ways this lack of control seems very much like a bug, but even missing features or the correction of poorly designed/implemented features are still feature requests.
The options of "inverted" or "reversed" needs to be added for all scenarios.
It has become an increasingly standard feature to be able to switch the scrolling axis with a modifier key or button. But there are varying scenarios and logic for how the user expects that to work. While it is fairly well accepted that scrolling up takes you to the top of the page, there is less-defined consensus on whether scrolling UP should increase or decrease the elapsed time/playback position if the axis has been switched by a key or button.
The user should be able to configure separately for each axis how the volume and playback position are affected by the scroll wheel.
Another complication arised when scrolling is setup as "natural" — (to many this may seem to be anything but natural, but if you imagine that the movement of the finger flicking up is pushing up an underlying piece of paper in order to see what is at the bottom of the page, the logic becomes more clear). However, this becomes very counter intuitive when controlling the volume in VLC because now flicking up LOWERS the volume (because it is technically scrolling down)!
Another prime example is a trackball which either has an outer rotating ring for scrolling or one simply turns the ball on the same axis as a ring or a knob for scrolling. This can create extremely counter-intuitive situations, especially when the same rotation can represent either vertical or horizontal scrolling with the press of another mouse button or modifier key(s).
We do not have any standardized, well-established or deep-rooted history of using knobs to manipulate movement of the content on a screen/display/monitor; therefore, it is a matter of personal preference whether one chooses clockwise or counterclockwise rotation to scroll up or down — it is likely to be dependent upon the movement/gesture the user employs to manipulate the wheel (are they using a finger to move the top of the ring to the right, or their thumb to move the bottom of the ring to the left to generate clockwise rotation of the ring?).
However, knobs which rotate on this axis have a long history of standardized use to control increments and decrements of volume, for example, and I've never encountered technology with knobs which didn't conform to the behavior of clockwise representing increase. Without the ability to choose separately for each scrolling axis how playback/volume is affected in VLC we end up with some very counter-intuitive situations which are not solvable using any methods available to standard end-users such as the config software for these devices or the system control panels/settings.
Consider this scenario: a trackball with a rotating outer ring for scrolling. Clockwise rotation is configured for scrolling down. But, over a playing video in VLC this turns the volume down instead of up. And how is the position affected if the rotating ring is switched to horizontal scrolling? And as I described above, whether or not that makes sense to the user will depend on how that rotation is generated by their hand.
In many ways this lack of control seems very much like a bug, but even missing features or the correction of poorly designed/implemented features are still feature requests.