Actually move the kde files that were renamed in the last commit

1 files changed, 51 insertions, 0 deletions

diff --git a/tdecore/KCONFIG_DESIGN b/tdecore/KCONFIG_DESIGN
new file mode 100644
index 000000000..dfd9aa151
--- /dev/null
+++ b/tdecore/KCONFIG_DESIGN
@@ -0,0 +1,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 <pbrown@kde.org>