Animation: Fix kivy.animation.Sequence and kivy.animation.Parallel consistency

[gottadiveintopython]

fix #5204 #5443 #5929

[matham]

I wonder if has_animation_properties is a better name? And maybe it's better if its a @property?

[matham]

Oh, Never mind, the function already exists in master. I'll let someone with animation usage review it.

[gottadiveintopython]

yep it override Animation.have_prop...()
Thanks for the review.

[tshirtman]

Looks good to me, great that you added tests to cover the case, tests passed here and the change is straightforward, it's a bit sad to have duplication here, but maybe refactoring to remove it would make things more complicated (a new parent class?), i'm fine with that for now.

[gottadiveintopython]

Hi, and thanks for the review.

it's a bit sad to have duplication here

yep and I didn't come up with any good idea. Should I fix that like this?

class MoreNestedSequentialAnimationTestCase(unittest.TestCase):  # changed base class

    def setUp(self):
        ...

    def tearDown(self):
        ...

    def test_have_properties_to_animate(self):  # test only this method
        ...

And regardless of that, I'll fix test_have_properties_to_animate() like this

    def test_have_properties_to_animate(self):
        self.assertFalse(self.a.have_properties_to_animate(self.w))
        self.a.start(self.w)
        self.assertTrue(self.a.have_properties_to_animate(self.w))
        self.a.stop(self.w)
        self.assertFalse(self.a.have_properties_to_animate(self.w))

which should be better than current code.

[tshirtman]

I meant for the Sequence and Parallel to have a common method, (but i'm not sure which meaning of "like" you used here, if you meant "in the same way as", then ok). i.e:

class CompoundAnimation(Animation):
    def have_property_to_animate(self, widget):
        …

class Sequence(CompoundAnimation):
    …

class Parallel(CompoundAnimation):
    …

i think is slightly better than having the exact same method in two classes.

[gottadiveintopython]

ah I understand what you mean.

stop(), stop_property(), cancel(), have_properties_to_animate() are completely same. So moving them to CompoundAnimation, the base class. I feel that doing that loose some flexibility. But anyawys I'm doing that now.

[gottadiveintopython]

I'm analyzing several things, so don't merge this PR yet

[gottadiveintopython]

Sequence and Parallel are really buggy while Animation is not.
If I continue fixing those bugs, this PR will become not related to the issue(#5443).
So I'm probably going to make another PR since the issue was already fixed.

[tshirtman]

Yes, there are certainly bugs left in them, thank you for looking into it.

[gottadiveintopython]

np :)
well I updated the PR. Can you review it?

[gottadiveintopython]

thanks

[tshirtman]

I think adding a message to the exception would be better, but that got me thinking, maybe we could just use AttributeError("Can't lookup transition attribute of a CompoundAnimation") since this is accessed as an attribute. What do you think?

[gottadiveintopython]

Yep I agree with adding a message to the exception.
And about AttributeError, I can't decide because for me both looks fine. But according to the reference, AttributeError might be better.

[gottadiveintopython]

Because NotImplementedError means real implementation required, which is not our case.
so yeah AttibuteError is better I think.

[gottadiveintopython]

@tshirtman Hi, is it better to git rebase master and rewrite unit tests in pytest-style? or better to keep the current state?

[tshirtman]

Hey, if you are willing to, rebasing/updating would be great.

[gottadiveintopython]

Parallel never fires on_progress, and I think it's a corrent behavior. But it might confuse the user, so we may need to document it.

Or maybe Parallel should fire on_progress only when Parallel.anim1 fires on_progress.

[gottadiveintopython]

Might be better not to use ChainMap. Because if we re-implement it like this:

    @property
    def animated_properties(self):
        return ChainMap(self.anim2.animated_properties, self.anim1.animated_properties)

the user will be able to write anim2.animated_properties. The following implementation might be better.

    @property
    def animated_properties(self):
        return {**self.anim1.animated_properties, **self.anim2.animated_properties, }

[tshirtman]

in both case it's an object that is returned to the user, that they can write to, but that doesn't mean they can write to animation.animated_properties, unless the property defines a setter.

[gottadiveintopython]

Oh sorry, I meant this part

Lookups search the underlying mappings successively until a key is found. In contrast, writes, updates, and deletions only operate on the first mapping.

in the doc.

To prevent the user from writing to the underlying dictionaries(anim1.animated_properties and anim2.animated_properties), we need to implement it like either of

@property
def animated_properties(self):
    return {**self.anim1.animated_properties, **self.anim2.animated_properties, }

or

@property
def animated_properties(self):
    return ChainMap({}, self.anim2.animated_properties, self.anim1.animated_properties)

[tshirtman]

ok, that makes sense indeed. I guess the second one is a bit more efficient, as it doesn't unnecessarily copy data around, while still allowing to update the values for this animation (as they'll be saved in the first dict, they'll override values for the same key in the other dicts), and also they'll reflect updates to the animated properties of the underlying animations, in case they happen (and unless an overriding value has been put in the first dict, of course).

[tshirtman]

Parallel never fires on_progress, and I think it's a corrent behavior. But it might confuse the user, so we may need to document it.

Or maybe Parallel should fire on_progress only when Parallel.anim1 fires on_progress.

hm, if we can't then it's better not to document, i don't see how only firing for anim1 would be correct, ideally it would fire for both, and have the progress value take both durations into account (so if anim 1 is 3s and anim 2 is 2s, 1s into the first animation, we'd get progress at 0.2, 1/5th of the total), but i didn't check how hard it would be to implement that.

[gottadiveintopython]

we'd get progress at 0.2, 1/5th of the total

Sounds like you are confusing Sequence with Parallel. But anyways It may be better to keep the current implementation. If we change it to fire on_progress, it probably impact the performance, because on_progress usually is fired very frequently.

if we can't then it's better not to document

Ok, got it.

[tshirtman]

we'd get progress at 0.2, 1/5th of the total

Sounds like you are confusing Sequence with Parallel. But anyways It may be better to keep the current implementation. If we change it to fire on_progress, it probably impact the performance, because on_progress usually is fired very frequently.

🤦 you are right, maybe we could report based on the longest, but yeah, in any case, no need to think about that in this PR, it would be a new feature imho, to be evaluated independently.

if we can't then it's better not to document

Ok, got it.

👍

[gottadiveintopython]

@tshirtman
I believe the PR is mergeable. Could you check if it's ok or not?

we could report based on the longest

Yeah I agree with that way if we implement it.

[gottadiveintopython]

@tshirtman I mean Could you approve the PR?

[tshirtman]

sorry i missed the update (again). I'll approve now.