[Vm-dev] Disagreement on sign of mouse wheels

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Dec 31 12:01:30 UTC 2019

Hi Tom,

Le mar. 31 déc. 2019 à 08:26, Tom Beckmann <tomjonabc at gmail.com> a écrit :

> 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.
> 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
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.
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?

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.
> That's goodness!

> Tom
> On Mon, Dec 30, 2019 at 9:26 PM Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191231/1cd52a8b/attachment.html>

More information about the Vm-dev mailing list