Scroll wheel setting for mouse drag

[DD-P]

Image dragging now conforms to the reversed scroll wheel setting for all the different viewers.

This was a little big for one commit, so I've broken the commits down into refactoring and staged improvements.

[DD-P]

I need to evaluate this a little more to ensure correct behaviour with both standard and natural system scrolling settings when Horos is reversed and not. I am aiming for consistency between scroll wheel and dragging as per #290. Will reopen the PR shortly.

[fvpolpeta]

Thanks!

Fauze

[DD-P]

Background

This needs a little bit of explanation. Ignoring dragging a slider-thumb, there are two ways that mice and trackpads can scroll through a series: I'll call them scroll-wheel and scroll-drag. Horos has a preference for reversing the scroll direction since the early days of OsiriX: let's say standard and reversed. This setting only affected scroll-wheel however.

Some years after this preference was added, macOS itself (Lion, 2011) added a similar system setting. (Apple's reasoning was uniformity with the iPad model of directly pushing a page around.) Let's call these settings normal and natural with the latter pushed as the default.

So now the user can choose from a 2x2 matrix of standard or reversed and normal or natural, giving 4 options. Horos also needs uniformity of behaviour for the user's choice with scroll-wheel and scroll-drag.

Proposed Solution

Two principles:

1. Direction of motion between scroll-wheel and scroll-drag should not be in conflict
2. System scroll direction and Horos scroll direction should not be in conflict

So scrolling by either method down will result in moving down through the image stack, in 3 of 4 cases. Down <-> Up only occurs if the settings are standard and normal (ignoring the questionable sanity of the labelling!).

This PR (hopefully) achieves that aim across the five domains I could identify:

• 2D viewer
• Database browser
• Orthogonal 2D viewer
• Multiplanar viewer
• Curved multiplanar viewer

If you agree with the concept, please check the commits for any unintended breakages. I have deliberately not modified the UI, but maybe the preference label could be renamed or disabled when natural is already selected...

Cheers, DDP

[fvpolpeta]

Hi @DD-P - My colleague @brizolara will be reviewing this and will get back to you.

Thanks

[brizolara]

Hi, David,

Thanks a lot for such a detailed work!

1. Here with System Preferences natural and Horos Preferences reversed (which are both the default ones):

• scroll-wheel towards me goes caudal-cranial
• scroll-drag towards me goes cranial-caudal
  Can you confirm it?

2. Looking inside commits 9f09580 and 06decc8... looks like the person which set those local movie4Dmove hard-coded as NO was planning to, in the 4D Viewer, scroll vertically to change image slice and horizontally to change time slice. For me it makes a lot of sense and I would keep those just to keep the idea signaled...

[DD-P]

Thank you for the review. I'll check (and try to correct) for point 1. I'll re-do the PR to maintain behaviour and existing code paths as per point 2. It will hopefully take 2-4 days to fit this in.

[DD-P]

I tried to strip and re-push a new set of commits, but that action auto-closed the PR. I've made a new PR at #353, which looks to work correctly for me. I hope it addresses points 1 and 2 above and works as intended for you.

[UNNI65]

Hi HOROS team
I tried this
Disabled Option to reverse scrolll and set MacOS scroll to Natural. Horos 3v3.3.5 and MacOS Mojave
My trainees find it frustrating when trying to scroll CT scans.
The scroll wheel works as intended but mouse drags in opposite direction as intended.
Many thanks in advance.
UNNI65