|
|
|
|
|
|
|
|
|
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 <pbrown@kde.org>
|
