We should be calculating the relative scale change between each event using division, not subtraction.

E.g.

oldScale = 1.2
newScale = 1.7
difference = 0.5
current code scale = 1 + difference = 1.5
actual amount scaled = 1.7 / 1.2 = 1.41666666666667

Note the discrepancy between the actual "amount scaled" and what we apply to the view.

Need to rename the:

• repo,
• podspec,
• and classes.

This will allow us to reuse a good amount of the logic.

One idea is to visualize the anchor point of the view and to allow you to change it by tapping anywhere in the view. We could include labels showing the view's position in order to show what's going on with the underlying .position value when we change the anchor point.

All references are in the unit tests.

• All class names need to have an @objc(MDM...) name mapping.
• Should include an Objective-C unit test file called "ObjectiveCAPITests.m" that simply instantiates each of the public APIs. These tests are meant to flag any regression in Objective-C support. All other tests can still be written in Swift.

This must be run by a @material-motion/core-team member.

mdm release cut

Two space tabs throughout the code.

Spec: https://material-motion.gitbooks.io/material-motion-starmap/content/specifications/motion_family/direct_manipulation.html

Should compose out to Draggable, Pinchable, and Rotatable.

Blocked on #20.

All performer logic should be added to swift files in the src/private sub-directory.

See the Core Animation family for an example: https://github.com/material-motion/material-motion-family-coreanimation-swift/tree/develop/src/private

Spec: https://material-motion.gitbooks.io/material-motion-starmap/content/specifications/motion_family/direct_manipulation.html

This will allow us (and others) to reuse these classes in unit test targets.

Should include the following:

• Installation steps. (Steal the ones from here).
• Getting started example.

Assume that this repo is the entry-point for an application developer who has never used Material Motion before. We'll likely want to link to some form of "getting started with material motion" document. Life of a plan might be a good start, but we should have a swift version as well.

Gesturable likely doesn't need to conform to Plan because it doesn't do much on its own.

In general we should be conservative about which objects conform to Plan.

AdjustsAnchorPoint will be emittable by DirectManipulation and directly addable by clients composing directly-manipulable themselves.

Spec: https://material-motion.gitbooks.io/material-motion-starmap/content/specifications/motion_family/direct_manipulation.html

Only DirectlyManipulable should.

Rationale being that if you are using any of Pinchable/Rotatable/Draggable then it is very unlikely that you will want to modify the anchor point each time the gesture recognizer begins. This type of behavior only makes sense if you have all three plans operating in tandem (i.e. with DirectlyManipulable).

• Deprecate shouldAdjustAnchorPointOnGestureStart on all three APIs.
• Emit an anchor point change from DirectlyManipulable on gesture start.

Must be ran by a member of the @material-motion/core-team

mdm release publish 1.0.0

Spec: https://material-motion.gitbooks.io/material-motion-starmap/content/specifications/motion_family/direct_manipulation.html

UIKit's gesture recognizers include a slop region. This slop region isn't always desirable for direct manipulation scenarios.

We should explore how we might provide pinch/rotate/pan support without a slop region.

One option is to implement a new UIGestureRecognizer subclass. This means we need to implement our own velocity calculations, which poses a serious risk of deviating from UIKit's velocity calculation logic.

If we can somehow utilize the existing gesture recognizers that would be preferable.

This plan is somewhat too powerful in that it allows arbitrary blocks to be provided to it. This can leak separation of concerns back to the creator of the plan.

Example:

BlockGesturable(withGestureRecognizer: gesture) { gesture in
  // Dangerous: access internal state of the registering agent
}

See the ContinuousPerforming spec: https://material-motion.github.io/material-motion/starmap/specifications/runtime/Performer

This is leaking the implementation details of the plan.

Instead, let's just expose the gesture recognizers. We intentionally won't expose shouldAdjustAnchorPointOnGestureStart because we always want this property to be true for DirectlyManipulable.

The gesture recognizers are all let types right now. They should be vars.

Coverage is at 70% as of 3167a04.

Every public API needs to be documented.

Can verify this by running:

jazzy
open docs/index.html

and observing the percentage at the top of the page.

The gesture recognizer may already be added to a view — e.g. the parent view — so we may not want to be calling target.addGestureRecognizer ourselves in GesturePerformer.

• Add dependency to Podfile.
• Use CatalogByConvention view controller to instantiate the root view controller.
• Implement breadcrumbs on each example view controller.
• Add TableOfContents.swift file to root of catalog project.