Disagreement on sign of mouse wheels
Locked
Disagreement on sign of mouse wheels
 
|
Hi all, there is still an issue with horizontal mouse wheels with latest VM, and (Smalltalk sendMouseWheelEvents: true) When I sweep the trackpad from bottom to top (with two fingers on MacBook), I get negative yDelta on the 3 OS, OSX, linux, Windows, all good. When I sweep the trackpad from right to left (with two finders on Mac) , I get: - negative xDelta on OSX - positive xDelta on linux and Windows I don't know whether it's due to Parallels VM, or same on native windows/linux... Could someone confirm? If so, I don't know which sign to change, what would you expect? |
Re: Disagreement on sign of mouse wheels
|
|
Hi Nicolas, on my ubuntu, running with the synaptics touchpad driver and "natural scrolling" enabled, I get the same default behavior as you describe. You can double check that this is the expected behavior by finding a page in your browser that overflows horizontally and checking whether it also moves right as your fingers move right. I typically mod the horizontal axis via `xinput set-prop` to get consistent behavior on both axes. The libinput driver (an alternative to synaptics that is used by default on wayland to my knowledge) appears to send negative to the bottom-right on both axes by default. So, if your browser on linux behaves the same, you should likely just keep the signs unchanged and leave it to the user to make this behavior consistent/adapt it to their liking, as it is an OS preference. What you might also be interested in, I started integrating xinput2 into the OSVM: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/Cog...tom95:xi-experiment This enables "pixel perfect" scrolling events and multitouch on linux. In the branch I took the liberty to define a new event type for touch events (ignoring the existing work for iOS that appeared to opt for a generic complex event type). It is still a work-in-progress, as xinput2 requires handling devicechanged events on the application side and some other things like modifier masks changed, which I haven't taken the time to look into yet. And of course, the design for touch events would need to be discussed to get the most future proof and cross-platform-compatible version. Best, Tom On Mon, Dec 30, 2019 at 9:26 PM Nicolas Cellier <[hidden email]> wrote:
|
Re: Disagreement on sign of mouse wheels
|
|
Hi Tom, Le mar. 31 déc. 2019 à 08:26, Tom Beckmann <[hidden email]> a écrit :
Yes, all applications react consistently to trackpad scrolling: they obey "natural scrolling": we are directly dragging the screen with the trackpad. Except Squeak on MacOSX with my recent ScrollPane changes (inbox Morphic-nice.1613). You can observe reversed horizontal scrolling in an explorer with (Smalltalk sendMouseWheelEvents: true) on OSX, but not Linux nor Windows... I think that I should change the sign convention on OSX VM, but I'd like to understand why... The VM should use consistent conventions across OS, and respect user preference for scrolling direction (scrollbar or natural feel). I am not able to find the sign convention of NSEvent scrollingDeltaX. https://developer.apple.com/documentation/appkit/nsevent/1534871-deltax tells that deltaX it is -1 for swipe right. But I observe -xxx for scrollingDeltaX right to left... I cannot make a mental picture of events management with this documentation, maybe I missed the right one... User preference about direction can be queried here: It's seems that "natural scrolling" is indeed case of inverted, but wording is clear as mudwater. Even for vertical scrolls, documentation is blurred. Because Apple changed the orientation of y axis: - it once was origin top-left, positive toward bottom (this is natural console oriented direction for latin text). - it is now origin bottom-left, positive toward up (usual math conventions). It's possible to change coordinate system on views, but then, does this change NSEvent?
That's goodness!
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |