Add a new InfiniteAnimation #5344
Conversation
animation.go
Outdated
| // Start registers the animation with the application run-loop and starts its execution. | ||
| func (i *IndefiniteAnimation) Start() { | ||
| i.setupAnimation() | ||
| i.animation.Start() | ||
| } | ||
|
|
||
| // Stop will end this animation and remove it from the run-loop. | ||
| func (a *Animation) Stop() { | ||
| CurrentApp().Driver().StopAnimation(a) | ||
| } |
There was a problem hiding this comment.
I'm not a fan of how the methods of different types are interleaved. I'd much rather have all methods for one typ after each other in alphabetical order before the next type.
There was a problem hiding this comment.
To clarify: I'd rather have struct, methods, struct, methods and so on. I think that's how Go files generally are structured. Without your latest change it is struct, struct, methods, methods?
|
Whoops. Forgot to add the message again. I like the idea of this but I'm not entirely sure if this is the best API for it (not necessarily against but an animation that just passes random curve and duration seems a bit strange). :) |
That part is just an implementation detail hidden away from the public API. I did it that way to avoid having to do a much larger code change making the animation scheduler aware of a new type. The implementation details could always be changed later, though if you have any other suggestions for how to implement this, I'm all ears. |
There was a problem hiding this comment.
I think it makes sense to have a clean way to have such an infinite animation, rather than exposing the details in docs or example.
However the word "indefinite" sounds somewhat confusing - would infinite not be more intuitive (and match the progress widget wording).
|
I'm trying to re-run the Ubuntu tests to see if it is temperamental issue. |
Description:
Adds a new type of animation that has no curve or duration, and simply ticks a function every frame until stopped.
This will be useful in 2.6 to schedule an ongoing "update loop" to run on the main app thread, for example in the
fyne-io/liferepo to replace the goroutine that currently drives the updates.Note: Since this is implemented entirely using the existing animation type, it's debatable whether it's even needed as it can be fully implemented in user code with the current set of public APIs. However, it's more clean to have a public API specifically for this purpose and a Tick function that takes no arguments, instead of user code having to supply one that simply ignores its argument.
Also, it's possible other names could be more descriptive of its more general use case, like
fyne.FrameTicker?Fixes #4735
Checklist:
Where applicable: