Usage of config vs camera_config and separating them.

[Aathish04]

I'd like a bit of clarification as to what config and camera_config will contain, and which one is more suitable for which scenario.

As its name would imply, I think that camera_config is to be used exclusively by the Camera mobject and all of its inheritors. As such, it should probably contain configurations pertaining to the frame rate, the background colour, the resolution, and similar things.

config meanwhile, is probably supposed to contain more general configurations, such as the file output directories, the caching related configurations, the logging configuration, and similar.

Should config also contain entries that "should" belong in camera_config?
Currently, camera_config is just set to be equal to config, meaning that config contains stuff like the frame_rate and more, and camera_config contains stuff like the tex_template.

Similarly, should non-Camera objects use the values in camera_config? The vast majority of values taken from config are stuff like pixel_width, frame_height, and these are better suited to be in camera_config, but Scene objects often make heavy use of these values.

This ties in with #282 , since the main issue there seems to be that camera_config was itself supposed to be an entry in config, yet that does not appear to be the case.
An ad-hoc fix for #282 was to change config["camera_config"] to config, after which everything fell into place since all other objects looked for pixel_width and pixel_height in config, but shouldn't stuff like pixel_width and pixel_height go in camera_config anyway?

So, basically, what will config and camera_config contain? Will they contain duplicate values? Which objects can use which configs?

Mentioning @leotrs for his thoughts, since he wrote the config system.

[leotrs]

If I recall correctly, "camera_config" was a key in the config dictionary before I ever touched the config system. That's why you have some code that is looking for "camera stuff" in config, or even looking for config["camera_config"].

In fact, there are three different config dictionaries: config, camera_config, and file_writer_config.

file_writer_config is (I think) exclusively used only when manim is actually producing some output, and (I think) should never even be exposed to the user and should be kept for internal use only.

camera_config contains all of the geometry "stuff", like pixel_height and others. Some of this will be used by the user, while others are only used internally by Camera objects and such.

config contains all of the above, as well as other options that don't fit in either of the above.

TBH, a lot of the current stat of affairs was kept for backwards compatibility. In my ideal world, (i) camera_config would be called frame instead, (ii) some constants would be added to it, and (iii) it would be a namespace rather than a dictionary., (iv) it would be meant to be used by the user and not necessarily only by Camera objects. All of this would allow the user to write things like frame.top, frame.up, frame.pixel_height, instead of the clunkier and less-readable camera_config["top"], UP, and camera_config["pixel_height"]. Note that right now, edges ("top") and directions ("UP") are stored in different places. This is because one is a constant but the other one isn't. This is ugly. Further, the user would never really need to think about file_writer_config, and perhaps even config itself may be exposed to the user but used only rarely.

I'm all for addressing these shortcomings and having more PRs on this end. However, we need to make sure whether or not we want to retain backwards compatibility.

[Aathish04]

However, we need to make sure whether or not we want to retain backwards compatibility.

I thought that #98 already broke backwards compatibility? You mentioned here that it did, so I think we can go all in and clean up as many things as we can internally, doing our best to not change too many things that directly influence the end user.

[leotrs]

Yes it already does contain breaking changes, but we don't want to completely change literally everything and make it impossible for users to migrate.

For now, I say we leave things as they are, but we add the aforementioned frame, which should clean up a lot of code in user-space, while keeping camera_config and config["camera_config"] for backwards compatibility, and with a deprecation warning.

We will probably have to write a migration guide in the future as well.

[leotrs]

Closing this in favor of #337