Page MenuHome

Apple Magic mouse pan is opposite for view3d.rotate
Open, Confirmed, MediumPublic

Description

System Information
Operating system: macOS Sierra 10.13.6 (17G6030)
Graphics card: AMD Radeon HD 6750M OpenGL Engine ATI Technologies Inc. 4.1 ATI-1.68.21

Blender Version
Broken: version: 2.80 (sub 70), branch: master, commit date: 2019-05-20 06:34, hash: rB3184460ff7f4
Worked: (optional)

Short description of error
Orbiting around an object has an opposite direction while using Apple Magic Mouse or a MacBook trackpad's scroll.

Exact steps for others to reproduce the error

  1. Shift and scroll with Apple Magic Mouse — panning direction is correct.
  2. Scroll with the Magic mouse — orbiting direction is opposite.

My guess for this UX fix: ‘view3d.rotate' must be somehow negative for the 'mouse/trackpad pan’ action on macOS to conform with its natural scroll feature.

Details

Type
Bug

Event Timeline

Enable this option:
Preferences > Navigation > Natural Trackpad Direction

Brecht Van Lommel (brecht) triaged this task as Needs Information from User priority.

Are you saying it's wrong only for magic mouse, or for both magic mouse and trackpad?

Also, what is the definition of 'wrong'? On macOS, scrolling is opposite from some other platforms.

Is it different from other apps on macOS, or different from using Blender on other OS's?

Orbiting around an object has an opposite direction while using Apple Magic Mouse or a MacBook trackpad's scroll.

The Magic Mouse does not have a scroll wheel, in this case, it means panning and not scrolling.

When you pan to the right, the object rotates clockwise, it looks like the wrong way (the near side of the object moves to the left).
"Natural Trackpad Direction" fixes this.

Also in the menu, when panning, the selection moves in the opposite direction, "Natural Trackpad Direction" fixes this too.

UI panels panning and 3d view panning works well in both cases, with "Natural Trackpad Direction" and without.

There is no right or wrong, it's just different:

Either swiping makes it seem like you are grabbing the contents - ie the object or grid, OR it maps to grabbing the view on that content.

On macOS, scrolling is meant to move in the direction of the contents, whereas on Windows, scrolling moves in the direction of the view.

So, this discussion about right vs wrong is confusing - it's better to be specific.

Edit: You are right. Natural Trackpad Direction seems to make things consistent on macOS, so that you are always moving the contents. So yes, on macOS, that setting makes more sense to be enabled by default.

Is there a way we can technically do that?

Enable this option:
Preferences > Navigation > Natural Trackpad Direction

Thank you, this solved the problem! Enabling this by default on macOS (or maybe on all platforms) will make a lot of sense.

Magic Mouse doesn’t have a scroll wheel and it’s surface behaves like a trackpad for scrolling both vertical and horizontal. It felt strange that other actions with cmd or shift modifiers behaved naturally (cmd+panning down to zoom closer, shift+panning left to pan a viewport to the right), but the viewport rotation was opposite: if I just pan left, the viewport will rotate to the left. It made orienting in blender hard so I used a regular mouse. I recorded a side-by-side comparison of Apple vs a regular mouse for navigation.

I don’t have an Apple trackpad to test but I’m pretty sure it behaves the same as mouse (only panning is done with two fingers).

The "Natural Trackpad Direction" setting is only present on macOS
and is related to the system preference "Scroll direction: natural (Content tracks finger movement)", which is now enabled by default.

https://developer.blender.org/rB1dfb6404b78396988fedf5ad2bd111c6af13cf12

I guess then yes, it should be enabled by default, if it only affects Macs anyway.

Brecht Van Lommel (brecht) raised the priority of this task from Needs Information from User to Needs Triage by Developer.May 22 2019, 10:48 AM

Don't know how to triage - it's not really technically a bug, but the defaults probably should be changed.

Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.

I think we can triage as usual as this is something we want to change, right @Brecht Van Lommel (brecht) ?