Avalonia
Avalonia copied to clipboard
AvaloniaUI
PointerWheelEventArgs: Adds RawDelta
What does the pull request do?
In #7520 PointerWheelEventArgs.Delta was flipped when the user was holding down shift. This pull request adds a new RawDelta property which preserves the original Delta as it was before it was flipped.
The impetus for this issue comes from an issue in ScottPlot5, where the flipping of the scroll vector was confusing because we were already doing something else if the user scrolled while shift was held. For us, the scroll wheel was for zooming not scrolling, and horizontal zooming is kind of a weird concept.
What is the updated/expected behavior with this PR?
RawDelta should match the delta passed into MouseDevice.MouseWheel. It should also match PointerWheelEventArgs.Delta if the shift key is not held.
Checklist
I didn't add unit tests or documentation because I didn't find any for Delta, but if I'm looking in the wrong spot I'd be happy to add some
- [ ] Added unit tests (if possible)?
- [ ] Added XML documentation to any related classes?
- [ ] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation
Breaking changes
None
Obsoletions / Deprecations
None
Fixed issues
None
I don't think it's a good idea to add raw input here. We might better to redo previous PR by moving handling of Shift level higher (scroll presenter code?).
But it probably won't solve your problem, as macOS natively flips wheel if shift is preset.
You can test this PR using the following package version. 0.10.999-cibuild0022648-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]
We might better to redo previous PR by moving handling of Shift level higher (scroll presenter code?).
Probably, that's where I figured it belongs, I didn't want to do this because of backwards-compatibility concerns. Not to mention my unfamiliarity with the codebase.
But it probably won't solve your problem, as macOS natively flips wheel if shift is preset.
Yikes. Personally, I would still want a RawDelta that accounted for that, although then its name becomes somewhat confusing, is it the "raw" information from the mouse driver, or from the OS? I was never much of a fan of the name "raw" to begin with, so that can be changed if necessary.
I guess it hinges on whether you think this is an edge case you want to take on or leave to developers. FWIW ScottPlot already has a fix for this (although it'll need to be updated for MacOS) so it becomes a matter of whether you think enough other people are going to run into it.
Do you have some possible use cases?
Well, my own obviously, plot zooming in ScottPlot. But I think lots of similar controls often used the scroll wheel for zooming rather than scrolling, in which case the shift+mwheel combination is annoying. For example, maps or image viewers or editors. And while I suspect that Avalonia's exposure to video games is pretty low, they often use the scroll wheel, but rarely for scrolling.
In that case I think what you would need is to have only a number, not a vector. So if it was me to decide I'd add another property called DeltaScalar or similar which will be computed like this:
- The value should be the length of
Delta - The direction (
+or-) is chosen by the largest component
@maxkatz6 , @bclehmann what do you think about this idea?
I'm a little lukewarm on DeltaScalar, I think that might be something that users should implement themselves? Seems like there are edgecases when both the x and y components are non-zero, and I think there are multiple valid options there. You could take the component with the highest absolute value, you could prefer the y component, or you could blend them by projecting the scroll vector onto the line $y = x$. Unless x scrolling and y scrolling will always be in separate events, and thus at least one component must be zero.
I think in any case we should add some docs for PointerWheelEventArgs.Delta to indicate that it can be inverted when shift is held. I'm ok with doing that, I assume I can just add some csdoc comments for the property? That can be a separate PR if you'd like.
In my opinion, it will be cleaner to move this shift-scrolling to the scroll viewer instead of mouse device. Also I checked my macOS again. Shift scrolling works natively with a third-party mouse but doesn't work with magic touchpad.
In my opinion, it will be cleaner to move this shift-scrolling to the scroll viewer instead of mouse device. Also I checked my macOS again. Shift scrolling works natively with a third-party mouse but doesn't work with magic touchpad.
If that is possible, I also would prefer this. But we have to be careful as it may differ for different OS. But as you said, it looks like also on Mac it's not uniform behavior 🤷♂️ .
You can test this PR using the following package version. 11.0.999-cibuild0026214-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]