diff mbox series

ui/cocoa.m: replace scrollingDeltaY with deltaY

Message ID 20180703041343.2014-1-programmingkidx@gmail.com
State New
Headers show
Series ui/cocoa.m: replace scrollingDeltaY with deltaY | expand

Commit Message

Programmingkid July 3, 2018, 4:13 a.m. UTC
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.

Signed-off-by: John Arbuckle <programmingkidx@gmail.com>
---
 ui/cocoa.m | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Peter Maydell July 3, 2018, 5:49 p.m. UTC | #1
On 3 July 2018 at 05:13, John Arbuckle <programmingkidx@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
diff mbox series

Patch

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 2991ed4f19..e34714081d 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -803,7 +803,7 @@  - (void) handleEvent:(NSEvent *)event
              */
 
             /* Determine if this is a scroll up or scroll down event */
-            buttons = ([event scrollingDeltaY] > 0) ?
+            buttons = ([event deltaY] > 0) ?
                 INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
             qemu_input_queue_btn(dcl->con, buttons, true);
             qemu_input_event_sync();