I’m sorry if I’m taking my questions to the wrong place but for a while I didn’t know if what I was experiencing was a bug or a design choice, and if it were the latter I don’t really know where to go to voice my opinion that a strange choice has been made somewhere along the line.
Basically, I use gnome with wayland. I’ve been using blender via xwayland until recently when I found out libdecor supports gtk theming now. Which led me to find out that blender has had trackpad support for a while. Which would have been a joyous discovery if the way it was implemented was usable(ie not inverted) using gnomes ‘natural scrolling’ setting. I’m left to assume that I am in an extreme minority using blender on a laptop with a multitouch trackpad under wayland with libdecor installed.
I decided to go through the code to see if I could clumsily add a way of uninverting the rotation controls only to find out that there was already code in place to do just this.
Digging deeper I found where the event data is constructed (in GHOST_SystemWayland.cc)
And I’ve since found out that the way that blender is trying to detect if scrolling has been inverted is not supported by gnome yet.
HOWEVER!!! before anyone says or thinks silently “thats a gnome problem, bring it to gnome devs”
I still have a question, the actual question, for any devs that have touched trackpad functionality (especially Campbell Barton). And that question is: even if the inversion detection via wayland WAS supported by gnome why would someone want blender to not respect their system wide scrolling direction choice?
If I have this right the current design if functional would mean that no matter what I have my system wide scrolling direction set to blender would behave the same way (but only when rotating a 3d view).
That alone should demonstrate that something hasn’t been entirely thought out here but if its not convincing enough consider that panning using the shift modifier does not take scrolling inversion into account. Which means that if a user is using gnome’s ‘traditional scrolling’ rotating the view with the trackpad will be equivalent to dragging the mouse with the mmb pressed, but holding shift and doing the same will be inverted between the two.
That example is currently the case for both ‘traditional’ and ‘natural’ scrolling on gnome. Though once gnome allows blender to receive scroll direction information it will only be true for ‘traditional’ scrolling. The more sensible decision in my opinion is to skip detection of scroll direction all together and have view rotation via ‘natural scrolling’ match using mmb mouse dragging, and allow ‘Traditional scrolling’ to be consistently the inverse of the former. (Or the equivalent of is_inverted being set to ‘true’ in view3d_navigate_view_rotate.cc)
And if anyone complains that the direction isn’t consistent with using the 3d navgation gizmo tell them that what they want is to use whatever their system’s ‘Natural Scrolling’ equivalent is. As the longer this is not done the more likely there will be a small subset of people who unknowingly train their brains to want to scroll unnaturaly in 2d but naturally in 3d.
Sorry for the verbosity. Anyways let me know if this was the right place to post this, I was dissuaded from posting in the issue tracker via the bug submission tips, which admittedly did lead me to try harder to find out what was going on myself and build a better case for my thoughts.
Also I think this design quirk effects all trackpad users and not just wayland based linux users (though on systems where scrolling inversion can be detected I assume that only orbiting + panning via unnatural scrolling is wonky).