Slider issue with mouse wheel and Shift


#1

Hi,

 

I read the post on how to report bugs, but I can't find any reliable version info, not in the .CPPs nor in the readmes and all that.
The Introjucer App says it's v3.1.0, I only downloaded JUCE earlier this week, and -probably most importantly- I checked this in the current GIT and it's also there.
I think I found the culprit and could solve it, at least as far as I can tell.


So, here's the thing:

Drag or mouse wheel by themselves work nicely on a slider.
Shift + drag will intendedly add "velocity" to the change and make values fine tunable.

When holding Shift and scrolling the mouse wheel, the slider will also go into fine tune "velocity" mode ... but it will change the value into the wrong direction. So scroll mouse wheel up = adds to value, but hold Shift + scroll mouse wheel up = subtracts from value.

I found the offender to sit here:

modules/juce_gui_basics/widgets/juce_Slider.cpp
line 1014

const double newValue = value + jmax (interval, std::abs (delta)) * (delta < 0 ? -1.0 : 1.0);

My quick-n-dirty fix was to add another Shift-key-dependent factor into the calculation:

const double newValue = value + (jmax (interval, std::abs (delta)) * (delta < 0 ? -1.0 : 1.0)
* (e.mods.isShiftDown() ? -1.0 : 1.0));

Since I squeezed that in, the Shift + mouse wheel is now working as it should.
I'm really new to JUCE, so I've no clue if you already know about this or if I did something wrong myself... :)

Cheers,
Rob


#2

Hm, I should probably add that I swapped the check for ModifierKeys::ctrlAltCommandModifiers to the check for ModifierKeys::shiftModifier a few lines down, so that Shift will switch to velocity mode instead of Ctrl, Alt or Command.


#3

Maybe I'm misunderstanding something, but as far as I can tell the modifier doesn't make any difference to the scroll-wheel direction (?) And in fact, the modifier key doesn't actually affect the scroll-wheel behaviour at all..


#4

Hate to say it but... it does here. :)

My XCode console tells me that JUCE is v3.1.1, and I'm on OSX 10.10 with a Logitech Anywhere MX, if that helps anything.

When I scroll the mouse wheel up, the slider value increments.
When I scroll the mouse wheel down, the slider value decrements.
Which is correct.

When I hold Cmd and scroll the mouse wheel up, the slider value changes slowly but decrements.
When I hold Cmd and scroll the mouse wheel down, the slider value changes slowly but increments.
So by holding down Cmd, the mouse wheel data seems to become inverted.

This was the behaviour out of the box without any patching.
Since putting that simple inline-if into the newValue calculation, everything works as expected.
I've since moved on and made Shift the modifier for velocity mode instead of CtrlAltCommand.

When I now hold Shift and scroll the mouse wheel up, the slider increments its value slower.
When I now hold Shift and scroll the mouse wheel down, the slider decremets its value slower.
Which is the expected behaviour, I would think.

Just tried it again with an "unpatched" JUCE, slapped an empty Slider onto a blank App's GUI and it happened.
My XCode output tells me this [EDIT] only when using 10.6 SDK, but doesn't say this with 10.7-10.10 SDKs:

2015-02-17 01:25:25.904 ImageToResource[4265:163013] -_continuousScroll is deprecated for NSScrollWheel. Please use -hasPreciseScrollingDeltas.
2015-02-17 01:25:25.904 ImageToResource[4265:163013] -deviceDeltaX is deprecated for NSScrollWheel. Please use -scrollingDeltaX.
2015-02-17 01:25:25.904 ImageToResource[4265:163013] -deviceDeltaY is deprecated for NSScrollWheel. Please use -scrollingDeltaY.


#5

This might be dependent on the used OS X SDK, but shift + mouse wheel seem to switch between vertical and horizontal mouse wheel events if no horizontal mouse wheel is present (e.g. normal mouse vs. Apple track pad). The patch in the first post should therefore lead to all mouse wheel events going up while shift is pressed.


#6

Yeah, I think this is some kind of hack that either OSX or your mouse-driver is doing because of the type of mouse you have. I can't reproduce it with mine (even with my vertical-wheel-only mouse), and obviously to flip the wheel direction for everyone just because one mouse-driver behaves strangely wouldn't be a great idea!


#7

Wow, this really is mouse dependent.
I just tried it with a Logitech M185, one of the more basic models of their range, and there the "fix" doesn't work.

I scroll up with Shift held = velocity mode and decrement.
I scroll down with Shift held = velocity mode and increment.

Odd...

I have "Scroll direction: natural" in mouse preferences disabled, by the way.
So scrolling down should make values decrement and scrolling up should increment them.

The Logitech driver does give the option to add acceleration, but disabling that seems to screw up scrolling completely.
With no Logi driver acceleration, scrolling up does nothing and scrolling down actually scrolls up...

I'm lost. crying