Add a way to create an infinite animation

[Drew Weymouth]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

The fyne.NewAnimation API takes a duration argument and ends the animation after the given duration. I had thought that a duration of 0 might be used to create an infinite animation, but it does not, nor is it documented as such.

Is it possible to construct a solution with the existing API?

No. Closest thing is to use math.MaxInt64 as the duration which is about 290 years (which is good enough for all practical purposes but not clean code).

Describe the solution you'd like to see.

An API fyne.NewIndefiniteAnimation(tick func(f float64)) or a clarification of the existing fyne.NewAnimation that 0 can be used for infinite duration (since an animation of duration 0 is not useful anyway.

[Andy Williams]

Sounds like a nice feature request - but let's make it explicit as shown in the API you propose.
Something lasting for 0 milliseconds should not run forever,

[Drew Weymouth]

The design question is not so much what the constructor should look like, but can we reuse the same Animation type? Currently it's

type Animation struct {
	AutoReverse bool
	Curve       AnimationCurve
	Duration    time.Duration
	RepeatCount int
	Tick        func(float32)
}

And we have the public driver.StartAnimation / StopAnimation that take a *Animation so it's not possible to introduce a new type. We could do a new field Indefinite bool but for an indefinite animation the rest of the fields other than Tick don't really make sense

[Andy Williams]

We might be saying the same thing. I was meaning that it is clearly different to what Animation was built for, so let's not confuse things my having a magic number passed to one of the fields make this different type of thing happen.

At a behaviour level it's not really an animation but simply a synchronisation with the draw tick for some code isn't it?

[Andy Williams]

It might be helpful to clarify the use-case as in my head every animation goes from one state to another over a period of time. Even gif and other seemingly endless movement is finite in some way.

[Drew Weymouth]

The use case is really for 2.6 and beyond with the threading updates - a replacement for the goroutine update loop for the Life game, and similar cases. So we can put this aside for now.