constants.py cleanup and improvement

[XorUnison]

manimlib/media_dir.txt is deprecated and should be removed, and the constants.py file should be brushed up as well.

Most notably the constant MEDIA_DIR currently gets completely ignored due to always being overwritten by this part of the code:

        if config["media_dir"]:
            MEDIA_DIR = config["media_dir"]
        else:
            MEDIA_DIR = os.path.join(
                os.path.expanduser('~'),
                "Dropbox (3Blue1Brown)/3Blue1Brown Team Folder"

This causes manim to always create a media folder in the location of the executed py file containing the rendered scenes.
Just removing the else statement is enough.

The original DIR lines might also be changed to immediately imply raw text input for obvious reasons (you know, with \ being used for win folders, but also escape characters).

MEDIA_DIR = ""

↓

MEDIA_DIR = r""

Adding a 4K rendering constant might be prudent, although linking it to an argument would happen in some other file I don't know out of my head.

I've also spotted at least two text issues:

1. Two times 'both' in a sentence that triggers when media_dir is redundantly specified in the terminal.
2. -p referring to low quality output, even though it's only triggering a preview, that is firing the mp4 into its assigned program.

And the file could use some serious commenting to make it easier for others to get into what's going on. I'm willing to work on that and submit a PR for that.

[leotrs]

@XorUnison is this issue really about constants.py, as the title suggest?

[XorUnison]

Yes, just to clarify, this issue is all about the constants.py, except maybe for the single line of code to add a 4K argument.

[PgBiel]

We should make a separate configuration file for stuff like media_dir and whatnot; .cfg seems like a nice option

[eulertour]

The directories really shouldn't be stored as global variables at all. They should be stored as part of the config and passed to scene_file_writer (or anything else that needs them) that way.
That would eliminate the need for weird workarounds like this.

[leotrs]

I agree @PgBiel there should be a .cfg file. We seem to be converging on this. Any PR takers?

[PgBiel]

Any PR takers?

I'd be willing to help on this one

[leotrs]

Thanks! @XorUnison is also assigned to maybe confer with them too!

[XorUnison]

Right, but I've been mostly for now focused on fixing what's there, and I don't have any particular plans for how to restructure it to ditch the global variables. If we make a whole separate .cfg file that's probably gonna be a bigger thing, won't it?

[XorUnison]

Oh right, we might also want to get the review and merge on #26 done first if we do the whole .cfg business here.

[leotrs]

Agreed #26 should come first