[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] ui/cocoa.m: replace scrollingDeltaY with deltaY
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH] ui/cocoa.m: replace scrollingDeltaY with deltaY |
Date: |
Tue, 3 Jul 2018 18:49:29 +0100 |
On 3 July 2018 at 05:13, John Arbuckle <address@hidden> 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