Replace Navigator with AnimatedNavigator

@radderz Do you think, that we need new functions for this? Wouldn’t it be not enough, if we set in all function the duration value to zero? As you can see, AnimatedNavigator checks always for duration == 0 and if true, it does the same as the old Navigator. So where is the advantage to have new functions?

[charlenni]

The main Navigator will have all of the current animation (and some more), so users do not have to switch back to the AnimatedNavigator.

AnimatedNavigator was made to replace the existing Navigator. It has the same functions plus a FlyTo function. @radderz added a FlingTo for the fling function. All other functions are only usefull, if Viewport gets more properties, which could be manipulated by the Navigator.

The only thing I could imagine is to add arguments for the easing function of an animation.

We still have an interface which includes the animation logic. It it is overriden animation logic can be ignore. I don’t see an actual use case for this but perhaps someone has already overriden it.

Radderz changes to INavigator made it ready for animations.

The AnimatedNavigator can be deprecated.

Yes

What more changes should go into that MR? What should further be tested?

• We should update the MapControls for this behavior.
• We should use the fling for all MapControls and check the zoom functions, if there are any (e.g. the mouse wheel zoom in Wpf).
• We should check, if System.Timer is the correct timer for this work or if we should replace it by a special timer for this work.
• We should think about the time steps of the timer. Perhaps 16 ms is to long.

[pauldendulk]

Reduce the Viewport to just public state, no methods. The current methods would be extension methods (I had this in mind also for other reasons).

There are only a few functions in Viewport:

• Transform(): Is used to move the center of the Viewport in touch events. Should be moved to Navigator.
• All conversions between screen coordinates and world coordinates. I assume, that you want to do this by extensions.
• Anything else is state related. The Set… functions could be replaced by access of the properties.

Yes, that is what I had in mind. With the WindowExtent still a readonly property.