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 KConfig 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
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 KConfig
objects should be changed to take pointers to KConfigBase 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
implemented at runtime without changing other code.
Similarly, there is a abstract data type KConfigBackEnd. 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
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
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
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
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
for ideas. Likewise if you want to implement a backend, look at
KConfigINIBackEnd 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 <[email protected]>
|
