Configuration options for "autostart" and initial "delay".

[ghost]

A configuration option "autostart" should be added that will allow a tween to not start when it is created, leaving that to the user to decide (calling "start"). The "seek" feature should also work with "autostart: false", and, when the "start" is called on a sought tween, it should behave like a resume from that location. This is a bit deeper, really needs some discussion.

And initial "delay" is also a must-have config option. This will allow a tween to do "nothing" for a certain amount of time before starting. I know, this could be done with a "beforeTween" hook, but having it front-and-center in the library would be of much higher importance.

[ghost]

Please, also, take a look at Actuate tweening library ( https://github.com/openfl/actuate ) it has a complete set of first-class features.

[jeremyckahn]

An "autostart" option seems appropriate. However, I'd prefer not to add additional APIs such as Tweenable.prototype.start, in order to keep things simple. Here's how I'm envisioning this would work:

var tweenable = new Tweenable();
tweenable.tween({
  from: { x: 0 },
  to: { x: 10 },
  autostart: false
});

// ... Then, sometime later in the code
tweenable.resume();

.resume should be sufficient here, as that is how the tween is initiated anyways.

As for a delay option, I would prefer not to add this to Shifty. I have another library called Rekapi that focuses on animation sequencing like this. Rekapi uses Shifty for its internal tweening logic. Shifty's focus is on minimal but effective tweening functionality, and I feel that a "delay" option adds a bit of ambiguity. For example, if I delay a Shifty tween by 10 seconds but call .pause() two seconds in, what happens with the delay? It's not immediately clear to me what should happen, but more importantly, it might not be clear to users depending on this functionality. Rekapi is built around the notion of an animation timeline with a robust set of playback and sequencing APIs that can handle this. It sounds like what you are building requires a more full-featured sequencing solution, and I think that Rekapi might work better for you than Shifty.

I can build in the "autostart" functionality when I have some time, but let me know if you'd like to address it sooner yourself.

[jeremyckahn]

I'm working on an implementation of "autostart," but now it seems that it's redundant due to #37. Do you have a use case where calling tween after setConfig is insufficient?

[jeremyckahn]

Ahh... now I see that setTimeout sets the timestamp of the tween. That should probably happen in tween. This seems like a bug, I'll address it.

[jeremyckahn]

I've got a patch in works in the feature/reset-tween branch, but I'll hold off on this until you let me know about your use case.

[ghost]

First of all, I appreciate the fact that you are addressing and fixing/upgrading things quickly (unlike other GitHub authors - no names given). Secondly, one of my use cases is a wrapper over a collection of tweenables. They all have to start at the same time, some time in the future, user-reuqested.

[jeremyckahn]

I always try to respond to issues quickly, I don't want to keep people blocked. :)

I think your use case could be served by initializing Tweenable instances, setting them up with .setConfig, and then calling .tween for each one based on user interaction at some point in the future. Admittedly there's a bug that will prevent that from working right now, but I am addressing that in https://github.com/jeremyckahn/shifty/tree/feature/reset-tween and will try to have that merged and released later today when I have time.

[jeremyckahn]

I just released 1.3.2. It doesn't implement the API you suggested, but it should address your use case.