[WIP] Dynamic configuration framework

[375gnu]

The problem:

• Currently configuration file is read by frontend while actual consumers are spread over the code. In current implementation frontend must know everything about configuration options, i.e. their types, valid values. There is an example for SolarSystemMaxDistance used in render.cpp:

src/celestia/qt/qtglwidget.cpp:    appRenderer->setSolarSystemMaxDistance(appCore->getConfig()->SolarSystemMaxDistance);
src/celestia/configfile.cpp:    configParams->getNumber("SolarSystemMaxDistance", maxDist);
src/celestia/configfile.cpp:    config->SolarSystemMaxDistance = min(max(maxDist, 1.0f), 10.0f);
src/celestia/configfile.h:    float SolarSystemMaxDistance;
src/celestia/win32/winmain.cpp:    appCore->getRenderer()->setSolarSystemMaxDistance(appCore->getConfig()->SolarSystemMaxDistance);
src/celestia/glutmain.cpp:    appCore->getRenderer()->setSolarSystemMaxDistance(appCore->getConfig()->SolarSystemMaxDistance);
src/celestia/gtk/main.cpp:    app->renderer->setSolarSystemMaxDistance(app->core->getConfig()->SolarSystemMaxDistance);

So not only routines responsible for celestia.cfg reading aware of this option but GUI code as well. While the latter can be fixed with some common routines in celestiacore.cpp this will not make out config code more robust.

• Configuration files are read on application startup only, to reconfigure we should restart it.

• Frontends save some different options using their specific methods so Gtk or win-native frontends are unable to read configuration saved by Qt frontend and vice verse.

So the requirements:

1. Any limitation on a configuration option should be applied on a consumer's side.
2. Config reader should just parse the file and put it into a structure designed for it. This will allow us to keep plugins' configuration in the same file, without any need for per-plugin config files.
3. Our code should provide means to dynamically reconfigure options in runtime.
4. Our code should provide means to save configuration file, frontends should save only frontend-specific options like window position and size but not rendering options.

This PR is a very early attempt to provide such configuration framework, it provides only basic functions and even not integrated into Celestia codebase. src/celengine/testprops.cc provides an example of usage.

Let's discuss its pros and cons.

[pirogronian]

Btw I would be also happy to see Parser class integration.

[375gnu]

Btw I would be also happy to see Parser class integration.

What do you mean? Parser is an absolutely independent entity, it's only required to parse files.

[Adriankhl]

I generally agree on the direction, have to take a closer look to comment on the actual implementation.

[Adriankhl]

By the way, I realize that something like DATADIR (which is related to SPLASH_DIR, etc. ) are hard-coded in compile-time, is it better to load these in runtime through the configuration process?

[375gnu]

By the way, I realize that something like DATADIR (which is related to SPLASH_DIR, etc. ) are hard-coded in compile-time, is it better to load these in runtime through the configuration proc

Good point

[pirogronian]

I meant Array and Value classed from parser.h

[375gnu]

I meant Array and Value classed from parser.h

I will. Currently it's just a proof-of-concept so it doesn't contain all required code.

Instead of replying I edited your comment, lol