Make _Animation.stop() always advance to the end by default and remove the optional gotoEnd parameter

[ptwobrussell]

Per a previous discussion with phiggins, I'm logging this in so I can keep an eye on whether or not it gets implemented (or get schooled on what I'm misunderstanding)

After reviewing the exposed methods for an _Animation, it seems to me that the API would be cleaner and less confusing if stop() always advanced the _Animation to the end versus taking the optional (non-default) arg gotoEnd=true. My rationale is that it is useful to pause() then play() an animation so that it picks right back up where it left off. But by default, it seems that stop() then play() does the very same thing by default. To stop and then have an _Animation restart from the beginning upon playing again, you have to do a stop(true) then play().

Having stop() always advance to the end makes the pause/play and start/play combinations seem more natural and has the effect of stop providing an extra step of gotoPercent(0) for you automatically.

Unless I'm missing something that happens elsewhere in dojo.fx it just doesn't seem like the current implementation for stop is as clean and straightforward as it could be in that regard.

[bill]

Removing that option sounds scary to me. If you started to open a title pane and then halfway through decided to close it, there would be a jump in the animation when stop() was called.

[ptwobrussell]

i see what you mean. so what i'm not getting is exactly what stop does for you there that pause doesn't do (besides imply finality to the operation). if that's the case, maybe pause should be axed and stop() would act like pause where as stop(true) would act like a "stop and quit".

[dante]

while I like and agree with this ticket, I think it is a big change internally as we've all treated _Animation as public more or less, or at least the public methods exposed in it via the fx methods. It scares me.

[bill]

mark all (open) tickets w/blank milestones to be "tbd"; their milestones need to be set to a version number or to "future"

[dante]

I'm still scared of this change. The implications are subtle and far-reaching.