On 3 July 2018 at 05:13, John Arbuckle <programmingk...@gmail.com> wrote: > The NSEvent class method scrollingDeltaY is available for Mac OS 10.7 and > newer. Since QEMU supports Mac OS 10.5 and up, we need to be using a method > that is available on these version of Mac OS X. The deltaY method is a method > that does the same thing as scrollingDeltaY and is available on Mac OS 10.5 > and up. So we simply replace scrollingDeltaY with deltaY.
I think that this change will result in scroll events from high-scrolling-precision devices (eg magic trackpad) sometimes giving the wrong kind of event. In particular, this comment from a random Eclipse bug report has a good description of what happens: https://bugs.eclipse.org/bugs/show_bug.cgi?id=220175#c13 For high-precision scrolling devices, the app gets events which: * have hasPreciseScrollingDeltas true * have scrollingDeltaY something non-zero * may have deltaY be zero So if we use ([event deltaY] > 0) ? INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN then for a slow upward scroll on a high precision device some (most) of our up-scroll events will appear with deltaY == 0, which this ?: will interpret as a WHEEL_DOWN event. Two choices I can see here: (1) make the code ignore ScrollWheel events with a deltaY of zero (ie don't inject any QEMU button wheel event for them). Would need to test on a 10.7+ system with a suitable precise-scrolling device that this does actually still allow scrolling. (2) use scrollingDeltaY on OSX versions that have it, and only use deltaY on the older versions. PS: could you line-break your commit messages, please? They seem to be coming out as all one very long line. Recommendation is hard linebreaks at about 70 chars per line. thanks -- PMM