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

1 files changed, 0 insertions, 51 deletions

diff --git a/kdecore/KCONFIG_DESIGN b/kdecore/KCONFIG_DESIGN
deleted file mode 100644
index dfd9aa151..000000000
--- a/kdecore/KCONFIG_DESIGN
+++ /dev/null
@@ -1,51 +0,0 @@
-
-              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>