summaryrefslogtreecommitdiffstats
path: root/kdecore/KCONFIG_DESIGN
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-11-06 15:56:40 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-11-06 15:56:40 -0600
commite16866e072f94410321d70daedbcb855ea878cac (patch)
treeee3f52eabde7da1a0e6ca845fb9c2813cf1558cf /kdecore/KCONFIG_DESIGN
parenta58c20c1a7593631a1b50213c805507ebc16adaf (diff)
downloadtdelibs-e16866e072f94410321d70daedbcb855ea878cac.tar.gz
tdelibs-e16866e072f94410321d70daedbcb855ea878cac.zip
Actually move the kde files that were renamed in the last commit
Diffstat (limited to 'kdecore/KCONFIG_DESIGN')
-rw-r--r--kdecore/KCONFIG_DESIGN51
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>