diff options
Diffstat (limited to 'tdecore/KCONFIG_DESIGN')
| -rw-r--r-- | tdecore/KCONFIG_DESIGN | 32 |
1 files changed, 16 insertions, 16 deletions
diff --git a/tdecore/KCONFIG_DESIGN b/tdecore/KCONFIG_DESIGN index dfd9aa151..d0fa141ff 100644 --- a/tdecore/KCONFIG_DESIGN +++ b/tdecore/KCONFIG_DESIGN @@ -1,9 +1,9 @@ - The basic design on KConfig for KDE 2.0 and KDE 3.0: + The basic design on TDEConfig for KDE 2.0 and KDE 3.0: ---------------------------------------- -KConfig is a hierarchy of classes for loading and saving configuration -data in KDE. KConfigBase is an abstract data type (ADT) with pure +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 @@ -15,34 +15,34 @@ 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 KConfig -objects should be changed to take pointers to KConfigBase objects. +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 KConfig that has been +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 KConfigBackEnd. All +Similarly, there is a abstract data type TDEConfigBackEnd. All reading/writing of the physical, on-disk configuration should be done -through a subclass of KConfigBackEnd. The only class that is -currently implemented right now is KConfigINIBackEnd, which +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 KConfig and KSimpleConfig hardcode that -they are using a KConfigINIBackEnd in the constructor. If more back +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 KConfigBackEnd, so the actual type of backend does not +pointer to a TDEConfigBackEnd, so the actual type of backend does not matter. -If you are interested in using KConfig, you need simply to look at the -public members of KConfigBase. They will provide you with everything +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 KConfig format, look at KConfig +are interested in implementing a new TDEConfig format, look at TDEConfig for ideas. Likewise if you want to implement a backend, look at -KConfigINIBackEnd for inspiration. The KDoc-style API documentation +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. |