remove beta tag & release it officially.
- D10870 / rEFL33bf1036e900: Efl.Ui.Vg_Animation: Remove @beta mark
D11212 / rEFL7e7496f25a37: Efl.Player: Move autoplay/playback_loop from Efl.Ui.Vg_Animation
D11061 / rEFL2f4ca46544c9: Efl.Ui.Vg_Animation: Change property name autorepeat to looping
D11022 / rEFL3a4c5cf6a5f3: tests: Add test cases for Efl.Ui.Vg_Animation
D11100 / rEFLe71cfba201d9: elementary_test: Apply changed event related to Efl.Ui.Vg_Animation
D11080 / rEFLa63306a90878: efl/player: merge in and rework events from vg_animation
D10953 / rEFLe3b77fcff8e9: Efl.Ui.Vg_Animation: Implaments Efl.Playable interface
D10939 / rEFL43288c7acec3: Efl.Ui.Animation_View : Change class name to Efl.Ui.Vg_Animation
D10931 / rEFL3dc3deba6280: Efl.Player: Add setter of playback_progress
D10915 / rEFLbaa1e6553bc9: Efl.Ui.Animation_View: Change state name
D10862 / rEFLe1afc7c1816e: Efl.Ui.Animation_View: Implements Efl.Player interface
- Mentioned Here
- T8589: implement missing efl.player methods for image and image_zoomable
D11061: Efl.Ui.Vg_Animation: Change property name autorepeat to looping
D11022: tests: Add test cases for Efl.Ui.Vg_Animation
D10870: Efl.Ui.Vg_Animation: Remove @beta mark
D10953: Efl.Ui.Vg_Animation: Implaments Efl.Playable interface
D10939: Efl.Ui.Animation_View : Change class name to Efl.Ui.Vg_Animation
D10862: Efl.Ui.Animation_View: Implements Efl.Player interface
Implements Efl.Player interface
.speed.set => Efl.Player.playback_speed.set
.speed.get => Efl.Player.playback_speed.get
.progress.get => Efl.Player.playback_progress.get
.play => Efl.Player.playing.set(true)
.stop => Efl.Player.playing.set(false)
.pause => Efl.Player.paused.set(true)
.resume => Efl.Player.paused.set(false)
New feature API
On other platforms that implement lottie animation, the class name is defined as AnimationView. This name definition follows it.
I think we can redefine Animation_view as AnimationView.
But I think, renaming the class is a big risk. Do you have a better idea?
Well, being consistent with other toolkits is important, but being consistent with ourselves is more important :)
We have fought very hard in other areas to avoid using the word "View" when the widget was not related to MVVM.
Why do you think renaming the class is a big risk?
Let's think about a better name. This is the description of this class:
Animation view is designed to show and play animation of vector graphics based content. It hides all @Efl.Canvas.Vg.Object details but just open an API to read vector data from file. Also, it implements details of animation control methods of Vector.
The current name clearly fails to mention "vector graphics". Why not Efl.Ui.Vg_Animation?
Or Efl.Ui.Vg, since the content does not need to be animated, right?
Another topic: This class has a method to report duration, which is already in the Efl.Playable interface. To keep consistency, this class should implement Efl.Playable.
Current state with the D10870 series applied since I'm getting back into things:
class Efl.Ui.Vg_Animation ├ (P) autoplay ├ (P) autorepeat ├ (P) frame ├ (P) default_view_size ├ (P) state ├ (P) frame_count ├ (P) min_progress ├ (P) max_progress ├ (P) min_frame ├ (P) max_frame ├ (M) playing_sector ├ (M) value_provider_override ├ (E) play,start ├ (E) play,repeat ├ (E) play,done ├ (E) play,pause ├ (E) play,resume ├ (E) play,stop ├ (E) play,update
Some comments (and I don't mind doing work here to resolve them if we want to make changes):
- Shouldn't Efl.Player have these signals? They seem like something every user of the interface would want.
- Same with autoplay and autorepeat potentially?
Otherwise I think this looks good? Let's try to get this hashed out within the next week or so. Thanks @jsuya for addressing all the concerns so far!
├ (E) play,start
├ (E) play,done
├ (E) play,pause
├ (E) play,resume
├ (E) play,stop
├ (E) play,update
├ (E) play,repeat
We can move the event to the Efl.Player as you say. But for this efl_canvas_video(emotion), elm_image and elm_image_zoomable must also be modified.
Do you want to implement this work in this task?
autoplay and autorepeat are different behaviors. It is described in docs
In some ways, however, the two names can confuse the same behavior.
(maybe people can think autoplay is to play again automatically when it's done. Is that correct?)
Do you want to change name to autoplaystart or autostart?
Regarding possible autoplay - autorepeat confusions:
I think autoplay is clear enough, and a common way of referring to this feature.
We can rename autorepeat to looping or repeating. This does not clash with anything else in our current API.
I've done the work to remove the events from this and put them in efl.player, so this is taken care of. We can independently evaluate the implementation of those events in existing efl.player interface users once we stabilize those events.
My remaining question is whether it's useful to have autoplay and autoplay/looping (which should actually maybe be playback_loop for consistency) as interface properties in efl.player. Looking at existing users (image, video, animation), I think autoplay would definitely be useful in all three. autorepeat is likely to be useful in image at a minimum for gif playback as well as animation, but I'm not sure I can see it being used in video at all?
To be clear, I don't see an issue with marking this stable for the release, but I want to avoid setting the precedent of marking things stable in the tree and then continuing to do lots of work on them, as this could easily spiral out of control and lead to us releasing incomplete API.
I think @zmike and I have already said that it seems useful to move autoplay to Efl.Player, and that it shouldn't be difficult to move looping too.
Nobody said anything against this idea, so I guess that's the way forward.
Also, if looping is moved to Efl.Player, I agree with @zmike that it should be renamed to playback_loop, for consistency with the other properties there.
I made that move autoplay and looping to Efl.Player and implements in Efl.Ui.Vg_animation.
but I didn't implements it in Efl.Ui.Image and Efl.Ui.Image_Zoomable( set @empty marker). I expect someone to implement this.
(I don't think this has anything to do with releasing a vector animation widget. I hope it will be done in a new task.)
class Efl.Ui.Vg_Animation ├ (P) frame ├ (P) default_view_size ├ (P) state ├ (P) frame_count ├ (P) min_progress ├ (P) max_progress ├ (P) min_frame ├ (P) max_frame ├ (M) playing_sector ├ (M) value_provider_override
This is the current state. I think this is reasonable?