1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
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>
|
