Feature Request: .ini configuration files

[wezu]

The .ini file format is almost a standard way to write configuration files. For game. On Windows. Usually.

Players faced with a .ini file have at least a chance to recognize it as a configuration file, and probably know what to do with it (I think even W10 by default opens ini files with the Notepad).

Panda3D on the other hand uses .prc files, and unless players used P3D before or read some instructions, they will not even know it's a configuration file.

Why not use .ini files as an alternative? A simple solution would be putting a load_ini_file_data function in panda3d.core that would do:

def load_ini_file_data (file_name):
    #import configparser
    Config = configparser.ConfigParser()
    Config.read(file_name)
    #builtins.Config = Config #add it to buildins?
    for section in Config.sections():
        for option in Config.options(section):
            #read all options as prc_file_data in case they have p3d meaning
            load_prc_file_data("", option +' '+Config.get(section, option))

[CFSworks]

Panda3D definitely has some heavy NIH syndrome with its file formats (.mf, .prc, .egg, .pz, .dc, ...), though in Panda's defense many of these were developed before the creation of the more industry-standard alternatives. Still, in the interest of modernization, we should work on supporting newer formats that beginners (or beginners' systems) can recognize immediately.

.ini's section-based organization might not fit in very well with how the PRC system is already organized - it makes it harder to change config variables from e.g. an in-engine developer console, for example. It's also not likely to help with the confusion on non-Windows platforms. But for sure, .prc is a bizarre file extension. Maybe adding .cfg to the standard search path and discouraging .prc would go a long way toward clearing up that confusion? Nonetheless, we should definitely have a broader discussion about how we want the PRC system to work (I don't like that it has some variables that don't take effect if changed after static-init time, how #t/#f is the syntax for true/false despite looking like a comment, how it's ambiguous whether an additional line is adding an entry to a list vs. modifying the previous value, etc.).

What are your thoughts?

[Moguri]

For the sake of completeness, I am mentioning #245 and #269 here. Maybe we need to a config/prc label?

[rdb]

I'm open to this as long as we reach concensus on how to deal with sections, and as long as we can do all this without having to maintain two config systems side-by-side. I would be against a duct tape solution like the snippet in @wezu's issue report.

Perhaps we could simply extend the existing .prc parser to also accept .ini style syntax, by adding support for sections, ignoring an equals sign after the variable name and picking up files with .cfg extension in any panda-specific (not root-level) config dir, as per #269?

With regards to supporting sections, my initial thought is that a section provides an implicit top-level prefix, so that this becomes an alternative way of setting vulkan-color-palette-size:

[vulkan]
color-palette-size = 32

That said, I recall that @CFSworks raised the objection in #245 that developers want to organise their files by intent, not by variable category, which I tend to agree with; it seems awkward to require developers to organise their files by subsystem.

Perhaps instead sections could function like "sub-pages" of a Config.prc file? The sections would not affect the namespacing of Panda variables, but Panda would still remember which section each variable was specified under, so that people could access individual config pages in a loaded .ini file by name and perhaps even toggle individual pages on/off or access their own variables under a specific page. One use case for this could be that users have two versions of the configuration under separate sections (eg. for different quality settings or per-user presets), and that users could choose to load only one.

FWIW, I agree that #t and #f is awkward, but Panda also supports 0, 1, or anything that starts with t or f, so I have already been discouraging the use of #t/#f in favour of true/false in documentation and sample code.

[Moguri]

Using sections for pages/sub-pages sound really useful to me. 👍

[Moguri]

Should this be strictly "ini," which doesn't have a spec, or would something ini-like with a spec such as TOML be better? TOML would be harder to hack in, and we'd have to figure out how to map things like tables into PRC.

[wezu]

TOML would be better because it has specs, but I'm not sure how/if tables (dictionaries?) would be useful. Could be ignored or mapped to a new ConfigVariable type (ConfigVariableDict?)

[rdb]

The main philosophical difference between TOML and .ini is that the former is structured and has explicit types. However, Panda's config system doesn't need the explicit typing info, since the types are all declared as part of the variable definition; and other than lists, it doesn't have any structured types. So I think INI is closer to the philosophy of PRC files than TOML is.

We should probably figure out what to do with lists if we go down the INI route.

[Moguri]

Yeah, after hacking things up for the equal sign PR, I agree with just keeping things loose and INI-like may be the better approach. It is certainly a lot easier approach than supporting TOML and may be "good enough."

[Moguri]

From PR #926

Do we want to enable this optionally, as part of a special mode for now (possibly toggled by extension), or do we want to allow this syntax for all .prc files?

I do not have a strong opinion on this, but I would lean toward just enabling the syntax for all PRC files. However, we do need to take care that we are not adding syntax/features that we will regret supporting in the future.