Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This modification allows
PanBehavior
to handle multiple pointers at the same time.When using a single pointer (mouse or single touch) it behaves in the same manner as before. When more than one pointer is used, it also gains the responsibility of zooming in/out the diagram if the pointers change distance (pinch to zoom)
Instead of adding the algorithms as private methods, I've added them as public methods in various locations. I have had copies of them as extension methods in my application anyway, so I thought other might find them useful as well. Do let me know if you think otherwise, or if there are better locations to put them!
Modifications:
Point
class gained aCalculateCentroid
static method to calculate the centroid of a set of pointsMouseEventArgs
gained aClient
property that combinesClientX
andClientY
into aPoint
. A shortcut, basicallyDiagram
class gained an overload for theSetZoom
method that accepts aPoint
to be used as the zoom origin. The logic was moved fromZoomBehavior
PanBehavior
got an overhaul to support multiple pointersThings I'm unsure of:
Should the new
SetZoom
overload clamp by the Minimum and Maximum zoom? I see that the originalSetZoom
only clamps the Minimum, but I'm not sure why. Perhaps something to do with the fit to screen action?Is it bothersome that
PanBehavior
now also has logic for zooming, while there's a separateZoomBehavior
?My thought in doing it that way is that
ZoomBehavior
is better off handling just zoom by wheel events. LeavingPanBehavior
to handle all pointer events. This way makes things simpler, because if I were to split the Pan and Zoom multi-touch logic, there would be a lot of duplicated code, as they're really closely related.I see the following options:
WheelZoomBehavior
andPointersPanZoomBehavior
. So instead of naming the behavior as the actions they do, it would be a combination of the events they listen to and the actions they can perform based on them.PanBehavior
code intoZoomBehavior
and make it listen to pointer events tooPersonally, I like option 1. But there's the impact of breaking code for people who reference these behavior directly in their codebase. Not sure how common that is, or if it's that significant. If it is significant, perhaps option 2? Would love some input about this
Closes #512