Fix darkroom scroll zooming on macOS using magic mouse and pinch zooming on 2nd window

[da-phil]

This PR tries to fix the following regressions caused in #20812:

• zooming via scroll gestures on macOS using the magic mouse stopped working (see comment RFC: How should darkroom zooming-in behave? #21027 (comment))
• pinch zooming on 2nd window stopped working (see comment RFC: How should darkroom zooming-in behave? #21027 (comment))

[da-phil]

@MStraeten can you please give this fix a try and share the logs? Thanks.
Does scroll zoom work while holding CTRL?

[MStraeten]

zooming by dragging on magic mouse and trackpad is fine - unless pinch and zoom was done on trackpad.
After that zooming in by mouse / trackpad is just possible in combination with control key. In a zoomed in view draging scrolls the view.

log.txt

[da-phil]

zooming by dragging on magic mouse and trackpad is fine - unless pinch and zoom was done on trackpad. After that zooming in by mouse / trackpad is just possible in combination with control key. In a zoomed in view draging scrolls the view.

log.txt

Ah yes, that's also the behavior on Linux with a mouse & touchpad, given that we cannot resolve the ambiguity between scroll-zooming (linearly moving both fingers up/down in parallel) and panning gestures (moving both fingers in either direction), without using another key to differentiate them. As far as I remember, dragging (moving mouse / single finger while clicking) has always been doing a panning motion.
I thought that the Apple Magic Mouse was doing something special here, it seems that it works the same as on Linux.

Then we come to the design decision which was

• requested in this feature request: Add pinch to zoom in and out for trackpads/touchpads #18048
• implemented in those PRs: add touchpad zoom and pan gestures #20356 & re-enable touchpad gestures with regression fixes #20451

The rationale:

Adds touchpad gestures in Darkroom:

pinch zoom in/out
two-finger pan

After above PRs were merged, two finger gestures (including the scroll one) became the panning gesture, just like the usual dragging works (holding left click / touchpad tap and then moving). And zooming is done with the dedicated and universally used pinch-zoom gesture.
At least I could verify locally on my Linux setup when going back before #20451 that this behavior changed.

Does reverting my PR / going back to a commit before my PR merged (e.g. d436623) bring back the behavior you expect?
This would be very surprising for me.

[da-phil]

zooming by dragging on magic mouse and trackpad is fine - unless pinch and zoom was done on trackpad. After that zooming in by mouse / trackpad is just possible in combination with control key. In a zoomed in view draging scrolls the view.

log.txt

By the way, thanks for the log file, this made the following clear:
The failure isn't "broken zoom" in general - it's that on macOS, Magic Mouse and trackpad share a GdkDevice instance, and after the trackpad pinch binds _touchpad to that shared device, every Magic Mouse scroll satisfies matches_last_gesture_device and gets routed to pan. Now clearing _touchpad on pinch END/CANCEL fixes the Magic Mouse case but as your description and log shows, it would re-break the design intent that trackpad two-finger drag should pan even without a prior pinch. The two fixes are mutually exclusive as long as we rely on device identity to discriminate them.

I need to have another look if I find more time later.

[masterpiga]

@da-phil apologies for derailing the conversation. Can this regression (jerky scroll in panels) be related to any of your previous changes in this area?

https://discuss.pixls.us/t/jerky-scroll-in-utility-and-processing-modules/57851?u=masterpiga

[da-phil]

@da-phil apologies for derailing the conversation. Can this regression (jerky scroll in panels) be related to any of your previous changes in this area?

https://discuss.pixls.us/t/jerky-scroll-in-utility-and-processing-modules/57851?u=masterpiga

Did you try a speculative revert of the merge commit in question?
Will have a look later, once I'm back home.

[masterpiga]

No, I haven't been following too closely, I have been quite short on time lately and I was wondering whether you thought that it could be related.

Edit: the bug is caused by #20801, apologies for barking at the wrong tree :) I filed #21084 to track the regression.

[github-actions]

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[Arecsu]

Fixed in #21659

[Arecsu]

To be more specific: 88e6de8

This one fixes and superseds this one.

[da-phil]

Fixed in #21659

Did this fix the issue @MStraeten?