Re: [Adonthell-devel] Configuration file support

[ksterker]

Hi everyone,

I have completed the configuration stuff. I hope to be able to commit things 
next weekend. Anyway, here are the details:

Config file is now in XML format, using libxml2. For reading the file, I'm 
using the SAX interface to parse stuff directly into our own data structures. 
For saving, a XML doc is created in memory and written to disk. No big deal ...

I tried my best to address the concerns of Alex and Sasha. For one, the config 
file itself contains practically no meta data at all. That means it is (a) 
simple and easy to edit and (b) it's hard to mess something up. Format is the 
following:

<Configuration>
  <Audio>
    <Channels>1</Channels>
    <Volume>75</Volume>
  </Audio>
  <Video>
    ...
  </Video>
</Configuration>

Internally, all data is stored as string. However, convenience methods exist 
that allow access as int or double, including conversion and error checking.

Right now, 4 types of configuration settings are implemented: BOOL for options 
that only have two states, FREE for those that allow arbitrary data, RANGE for 
integer ranges and CHOICE for a small list of predefined settings to chose from.

When a configuration is loaded, all values are read, but their type is set to 
UNDEFINED. Now, a module can request a certain option with a certain type, in 
which case the undefined option is cast to specified type and returned. It now 
is up to the module to add the constraints required by the GUI. Here's some 
pseudo code:

   // at startup
   configuration config;
   config.load ("adonthell");

   ...

   // in module video
   // read value from file
   int resolution = config.get_int ("Video", "Resolution");

   // access low level data
   cfg_choice *opt = (cfg_choice*) config.option ("Video", "Resolution", 
cfg_option::CHOICE);

   // set meta data for GUI
   // each possible choice has a label and a value
   opt.add ("320x240", "0");
   opt.add ("640x480", "1");

   ...


Obviously, the code may need some changes once we actually use it. For example, 
those configuratio::get_<type> methods should be passed a default value, so 
that they can create the option if it is not present yet. That way, it means a 
little less code in the individual modules.


I hope my explanations weren't too confusing. Things should become clearer once 
I can commit stuff. But if you have any comments, I'd like to hear them. 
Perhaps I can improve things already before I can commit the code.

Kai