-
Notifications
You must be signed in to change notification settings - Fork 539
mac: Don't interpret single-touch scroll events as pan gestures #1107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
To handle the Magic Mouse, whose single-finger touch gestures should be interpreted as scrollwheel events rather than pan gestures.
|
Going to merge this. Let's get some mac testing on it. |
|
@tomsci This PR "broke" trackpad scrolling a bit. I tried all kinds of things to differentiate between the Magic Mouse and "normal" Trackpads, to no avail. I think we might have the most luck by using the Without this PR, Trackpad works perfect, Magic Mouse does not. Have you tried implementing the I just attempted it over here and got it kind of working accept for the the offset being wrong, hoping you can help out =) |
|
@vespakoen I'm not sure I understand what you are seeing? I've just rebuilt from master, and if I do a two-finger drag on the trackpad I get the expected inertial scrolling that carries on for a bit after I stop touching the trackpad. I haven't seen anything that incorrectly triggers a zoom. What do I need to do to reproduce the problem you're seeing? |
|
Ah interesting... It happens when panning fast and lifting the fingers off while panning, more like "flicking"? I'll send a screen recording of the behaviour later. |
|
I'm using an 2015 intel MBP built-in trackpad on 11.6 Big Sur, and flicking seems to work ok for me, but the hardware is probably completely different to what's in a modern M1 mac. Or Monterey has changed how the APIs work, that's always a possibility too. I did notice you get weird interactions if you have a mouse connected and move that while the inertial scrolling is slowing down, the mouse movement affects the inertial scrolling when it shouldn't, but I'm not sure how one would fix that. I don't seem to be able to reproduce any weirdnesses using just the trackpad, even when doing lots of quick flicks in quick succession, cancelling the flicks by touching the trackpad again, etc. Regarding using a pan gesture recognizer, I did consider it and decided against, although it's long enough ago I can't remember the exact reason. Possibly I couldn't get shift-two-finger-drag to work with it either. The gesture recognizers are great when they do exactly what you want, but if they don't they're even harder to customise that just doing it yourself... |
|
Hope this makes sense: trackpad.mov |
|
I added some logging to the So there are scroll events happening after |
|
I think I just figured out that the This is probably the reason for not using the I guess the only way we can fix this is by adding a checkbox to the menu to change the behaviour, so it can work correctly with the Magic Mouse and Trackpads. |
|
@vespakoen a platform specific check box would be a first and sounds to me like a pretty bad idea. You should think carefully what it does, what would it be called an would it disappear when not on macOS? Also - how does other software on the Mac handle this? Do they have "a checkbox" |
|
Agreed I don't think we should have to resort to UI toggles for this. I think most other apps don't try and do such specific and advanced things with the mouse/trackpad, and aren't interacting with a cross-platform codebase that assume the mouse event model works in a particular way. Got to say, Apple's APIs for this are less than helpful when they're trying to be "helpful"... I'll take another look at this and @vespakoen's vid when I get a sec, hopefully there's something we can do that satisfies both usecases. If it really is super broken for the trackpad maybe we should just consider reverting this PR, and go back to having fully-working trackpad and somewhat-broken magic mouse? I'd speculate more people have either trackpads (thanks to being a mac laptop) or are using a standard PC-compatible mouse, compared to the number of people with Magic Mice. (I only have a PC mouse at home thanks to it being half the price, and actually works with PCs...) |
So it looks like this happened in #1218 unfortunately without mentioning this discussion and we now somewhat-broken magic mouse as a trade-off for having nice trackpad padding and no system specific settings. Afaik we should be able to get touch device type from: - (void)touchesBeganWithEvent:(NSEvent *)event {
NSTouch *touch = [event touchesMatchingPhase:NSTouchPhaseTouching inView:self].anyObject;
NSTouchDevice *touchDevice = (NSTouchDevice *)touch.device;
NSLog(@"touchesBeganWithEvent %p", touchDevice);
if (touchDevice != nullptr) {
touchDeviceType = touchDevice.deviceType;
NSLog(@"touchDeviceType %ld", touchDeviceType);
}
[super touchesBeganWithEvent:event];
}Interestingly this method does not fire at all on my Magic Mouse. I'll look into that on my MacBook later this week. Maybe we could actually distinguish if the touches come from Magic Mouse or any mouse or a trackpad in the end. |
|
From the top of my head: |
|
IIRC my old MBA trackpad allows 2-finger dragging to rotate and 1 finger to pan on Solvespace version 2.3 but the 2-finger doesn't work on 3.0+ It really was nice to not have to use modifier keys. |
To handle the Magic Mouse, whose single-finger touch gestures should be interpreted as scrollwheel events rather than pan gestures.
fixes #1106
@vespakoen does this look ok to you? Having to track the current number of active touches as an independent bit of state is slightly messy, but it does seem to do the trick without breaking actual trackpad support. Providing someone doesn't try zooming with a Magic Mouse single-finger gesture at the same time as panning with two fingers on a trackpad, I suppose...