@Phuket2, for what it is worth, I am running 11.2.5, and I do not get the error.
For the repeating wiggle, I would do:
@script def notice(view): while True: wobble(view) yield 5
Could also use different wait times, and could use the ease functions to calculate each wait.
fly_inare not implemented yet, they were just examples for the discussion, to get a feel for how the API would look and whether they would really match what you were looking for.
In terms of the finished look that you get with a little bit of animation here and there, I obviously agree.
Ok, sir @Phuket2!
First of all, a big thank you for all the ideas and feedback.
Regarding the ease functions, in the current version all functions are available as functions, i.e. can be found with autocomplete. Support for the string arguments was retained for backwards compatibility only.
Thus, instead of
ease_func='easeIn', just use
ease_func=ease_in. Function names are the same as in the reference graphic.
Regarding the demos not stopping if you click another button - yes, but I was too lazy to implement it. Also, you can get some crazy fun effects with the current setup.
appearand other similar PowerPoint-type "view introduction" functions do seem like a good idea. The challenge there is that in order to be animated, the view needs to in the view hierarchy, and thus you suddenly need to care where the view 'starts', not just where you want it to end up.
To avoid this, we could have the intro functions take an additional view as a parent view, then the function could take care of placing the view suitably before calling
add_subviewand running the animation. Not providing the parent would mean that the view would get presented instead.
would fade the root view into visibility, while
fly_in(child, 'from_left', 100, 100, parent=view)
would bring in a child view, after having added it as a subview.
This would be in line with the rest of the Scripter API, but would not really support the "view manages itself" philosophy.
Have you gone further with your experiment?