The basic design on TDEConfig for KDE 2.0 and KDE 3.0: ---------------------------------------- TDEConfig is a hierarchy of classes for loading and saving configuration data in KDE. TDEConfigBase is an abstract data type (ADT) with pure virtual functions which describes the API for accessing configuration data. It cannot be instantiated directly; only subclasses which actually implement the API may be created. The reason for this design is that different ways of storing configuration data in _memory_ may be desired. The default design uses a QMap (red-black tree) for storing values in memory once they are read from disk. However, a different design might use a shared database or something similar to achieve shared memory config values. The possibilities are endless, and with this design we insure that future designs will not break compatibility. This means that most classes that currently take pointers to TDEConfig objects should be changed to take pointers to TDEConfigBase objects. The virtual functions and c++ polymorphism will make sure that the correct function in the actual, instantiated object are called, but this lets the user/programmer change the type of TDEConfig that has been implemented at runtime without changing other code. Similarly, there is a abstract data type TDEConfigBackEnd. All reading/writing of the physical, on-disk configuration should be done through a subclass of TDEConfigBackEnd. The only class that is currently implemented right now is TDEConfigINIBackEnd, which reads/writes the standard windows INI-style configuration files that KDE has used since KDE 1.x days. However, it is conceivable that one might program an XML backend, or even a database/registry style backend. Again, this abstract data type approach provides flexibility for the future. Currently TDEConfig and KSimpleConfig hardcode that they are using a TDEConfigINIBackEnd in the constructor. If more back ends are implemented, this will have to be changed to use a factory method of some sort to create the backend; all they maintain is a pointer to a TDEConfigBackEnd, so the actual type of backend does not matter. If you are interested in using TDEConfig, you need simply to look at the public members of TDEConfigBase. They will provide you with everything you need to do to look up data, change and write data, etc. If you are interested in implementing a new TDEConfig format, look at TDEConfig for ideas. Likewise if you want to implement a backend, look at TDEConfigINIBackEnd for inspiration. The KDoc-style API documentation should be complete. If there is anything confusing, please either fix it in CVS yourself or mail me with your questions, and we will make sure things get clarified. - Preston Brown