Changing existing Mobjects

As agreed on in the Discord call here’s the issue on what to do about changing existing Mobjects.

Right now when creating Mobjects kwargs can be passed to instantly get a certain desired appearance:

c_config={"stroke_width": 10,"stroke_color": RED,"fill_opacity": 1,"color": BLUE}
c=Circle(**c_config)

So far so good. The issue starts when you have an object like…

c=Circle()

…and you want to change it afterwards. For instance the Tiling class I worked on takes a prototype tile, and replicates it, so instantiating objects the way they have to look is not an option, the attributes have to be adjusted after creation. For my big tiling video I then had to make a function changing the color of all tiles depending on position. This was okay for 1 color, but if I would’ve had to change multiple values things would’ve gotten very ugly, very quickly with manim as of today. Currently to affect these attributes we have to do stuff like:

c.set_fill(RED)
c.set_stroke...

And while…

digest_config(c,c_config)

…is a thing, we want to first get rid of digest_config, and second it only works for some attributes. digest_config like this will apply stroke width and presumably some other attributes, but not colors. They all have to be applied separately in their own statement. And third separate set_... methods are also undesired and should be kept to a necessary minimum. So this is all very very messy.

So the goal, aside from ditching the current way config works also has to be to streamline how attributes of existing objects are changed: So what currently is impossible but should be possible is something like this…

c_config={"stroke_width": 10,"stroke_color": RED,"fill_opacity": 1,"color": BLUE}
c=Circle()
c.change_attributes(**c)

yielding the same result as this:

c_config={"stroke_width": 10,"stroke_color": RED,"fill_opacity": 1,"color": BLUE}
c=Circle(**c_config)

change_attributes or whatever we call it should then ideally be one, singular and central method to change the appearance of Mobjects, deprecating most/all of these set_... methods in turn, and also not relying on digest_config. As for how to best implement that… I don’t know, so that’s for sure a point of discussion.

[XorUnison]

Related to #258

@XorUnison were you able to look into this?

Not until you mentioned that and me here anyway what with me being so annoyingly busy, I don’t get to sift issues indiscriminately.

But yeah, I ran into more of these issues, and they’re exactly the tangential issues that also need to be fixed when changing existing Mobjects. There are so many schisms in manim between attributes, setters and getters, and we should clean them all up eventually. #258 is just raising attention on one of the specific issues.

[behackl]

I think that this is actually resolved with the introduction of the .set compatibility layer. Further progress should be made into dynamically changing keyword argument default values.