Rack: V1: Implement Shift+Mousewheel to scroll horizontally like v0.6

Created on 28 May 2019  路  20Comments  路  Source: VCVRack/Rack

While using the new zooming feature I found myself automatically hitting shift to horizontally scroll with the mousewheel. I use this all the time in browsers (for long lines of text in github). I just thought it would work well with the new zooming feature.

Most helpful comment

Bug/faulty behaviour occurs when window is focussed. Horizontal scroll using shift + scrollwheel works properly when VCV window is unfocussed.

All 20 comments

Shift and mouse wheel scrolls horizontally already, doesn't it? :eyes:

in v0.6 yes, not v1 for me. I guess this is a bug report then :)

I can't reproduce the bug. What's your OS, Rack commit hash, and mouse hardware?

os: mac os 10.12.6
git hash: 2c147c2
mouse: logitech M510

I can open v0.6 and it works just fine.

oh weird, if the window doesn't have focus, it scrolls horizontally

also it does not go into this block when the window does not have focus https://github.com/VCVRack/Rack/blob/v1/src/ui/ScrollWidget.cpp#L106

If you're already debugging that deeply, what is the value of APP->window->getMods()?

The value is 1. It does go into the if block when the window has focus.

Then problem solved?

I don't want it to. If I comment out scrollDelta.flip() then everything works fine. Am I missing what you are inferring?

I'm not following this discussion clearly. What I understand is that

  • If the window is focused and shift is held, the scrollDelta is flipped and it scrolls horizontally

This is the expected behavior, right?

No.
If the window is focused and shift is held, then it DOES NOT work.
If the window is not focused and shift is held, then it works.
If the window is focused and I comment out scrollDelta.flip(), then it works.

its like scroll delta is already flipped for me for some reason

Works as expected on Windows any, wondering if this is just a Mac thing?

_Endianness_ probably not...

No.
If the window is focused and shift is held, then it DOES NOT work.
If the window is _not_ focused and shift is held, then it works.
If the window is focused and I comment out scrollDelta.flip(), then it works.

I can confirm this behaviour on my Mojave 10.14.5 mac min 2018 using a logitech bluetooth mouse and latest github version commit 8c89a50. Well, I havent tried messing with the code yet, but I can confirm the symptoms/behaviour is wrong when the window is in focus and correct when it isnt!

Just tried shift and scroll-wheel in Safari and it manipulates the horizontal scroll, so maybe this stuff is built into the OS and vcv rack is reversing this built in behaviour!

There does seem to be evidence of this existing on the system level on MacOS for very many years, I can find articles from 2008 and probably earlier if I put more time into searching.

eg: https://www.macworld.com/article/1132933/oldmicescroll.html

When this happens, is the window unfocused?

Bug/faulty behaviour occurs when window is focussed. Horizontal scroll using shift + scrollwheel works properly when VCV window is unfocussed.

I think I would describe this problem as "double-flipping". It looks like MacOS is taking care of flipping the scrolling behavior when shift is held, and then Rack does the same thing again, but only when the windows is focused.

The value of getMods() at that point currently looks like this:

| | Window focused | Window not focused |
|-------------| ----------------- | ------------- |
|Shift not held| 0 | 0 |
|Shift not held| 1 | 0 |

I tried removing the two-line conditional block and now it works for me like it should, so it looks like this logic should be omitted entirely in MacOS.

Okay, that seems to work with both trackpads and standard USB mice. Fixed in 4290287

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jaffasplaffa picture jaffasplaffa  路  7Comments

gogobanziibaby picture gogobanziibaby  路  4Comments

alectron picture alectron  路  6Comments

jonheal picture jonheal  路  4Comments

AndrewBelt picture AndrewBelt  路  5Comments