-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timing function updates #10
Comments
It's a remnant from a quick port job of Penner's curves. I think ultimately we want to leave those parameters in, as they can be quite useful and it bothers me that they're hard coded now. There's a question hanging in the air about best approach to this. One thought is to modify the functions to look like this: CGFloat PRTweenTimingFunctionElasticOut (CGFloat t, CGFloat b, CGFloat c, CGFloat d, NSDictionary *options) {
...
} In this case I think we'd expose it through a property on With shorthands, it could be handled in two ways. We'd get chaining for free: [PRTween tween:&someValue from:0 to:100 duration:1 timingFunction:&PRTweenTimingFunctionElasticOut].timingFunctionOptions = options; Or we could add/modify the method signature to include an options argument, something like What are your thoughts? |
I'd say add a new method signature (not modify) like the last one that allows you to send options dictionary, and have the original method just pass nil to that method. I think 9.9 times out of 10 people will just use the default values that are currently hard-coded, but I always prefer a "complete" API, ya know? Seems like a low priority update. |
Working on this and it should be up soon. As a side note, don't hit E by accident on the issues page. |
lol, I had to hit 'e' to test, naturally. |
Looking forward to the update. I submitted a quick pull request for a typo and a weird "/" I found inside one of the transition functions. |
Seems like the timing functions have been locked down and removed some of the original parameters from Penner's methods.
This for example is missing the amplitude and period params, so much of the logic testing for a isn't needed if you're going to hard code those values right? Just noticed this because when running Analyze you get "a evaluates to a garbage value." Any reason that you got rid of those parameters?
The text was updated successfully, but these errors were encountered: