Rename KCModule, KConfig, KIO, KServer, and KSocket to avoid conflicts with KDE4

1 files changed, 18 insertions, 18 deletions

diff --git a/tdecore/DESIGN.kconfig b/tdecore/DESIGN.kconfig
index 4ced76726..c4c68b28e 100644
--- a/tdecore/DESIGN.kconfig
+++ b/tdecore/DESIGN.kconfig
@@ -70,7 +70,7 @@ When an entry is read with readEntry(key, defaultValue), non-existing
 entries will return "defaultValue" while hasKey(key) will return "false"
 for such entries.
 
-Currently all entries are stored in memory. When KConfig is "sync()'ed"
+Currently all entries are stored in memory. When TDEConfig is "sync()'ed"
 it reads the file that it is about to overwrite (for the second time), it 
 then merges in the entries it has in memory and writes the result back to 
 the file. It does NOT update its map of entries in memory with the entries
@@ -99,12 +99,12 @@ KDE3.0 Changes
 
 ------------------------------------------------------------------------------
 
-KConfig XT
+TDEConfig XT
 ==========
 
-My buzzword picker offered KConfig XT ("eXtended Technology") and KConfig NG 
+My buzzword picker offered TDEConfig XT ("eXtended Technology") and TDEConfig NG 
 ("Next Generation").  Since the planned changes are ment to be evolutionary 
-rather than revolutionary, KConfig NG was dropped.
+rather than revolutionary, TDEConfig NG was dropped.
 
 Goals
 =====
@@ -130,12 +130,12 @@ Type information can be provide by preceding every entry with a formalized
 comment.
 
 Work to be done:
-* KConfig needs to be extended to provide access to the default values provided 
-by the default config files. KConfig already stores this information internally.
+* TDEConfig needs to be extended to provide access to the default values provided 
+by the default config files. TDEConfig already stores this information internally.
 (DONE)
 * A formal comment structure needs to be designed that can convey type-information.
 Preferably in such a way that it is easily parsable by both machine and user.
-* KConfig needs to be extended, or another class created, that is able to parse
+* TDEConfig needs to be extended, or another class created, that is able to parse
 the formalized comments.
 * A tool needs to be developed that can assist developers with the generation
 and verification of default configuration files including type-information.
@@ -170,34 +170,34 @@ Host=wantelbos.zogje.fr
 
 Class overview
 
-                       KConfigBase
+                       TDEConfigBase
                             |
                             v
- KConfigBackend  <-----> KConfig <------> KConfigSkeleton           /--< myapp.kcfg
+ TDEConfigBackend  <-----> TDEConfig <------> TDEConfigSkeleton           /--< myapp.kcfg
        |                    |                    |                 /
        v                    v                    |*---------------<
-KConfigINIBackend      KSimpleConfig             |kconfig_compiler \
+TDEConfigINIBackend      KSimpleConfig             |kconfig_compiler \
                                                  |                  \--< myconfig.kcfg-codegen
                                                  v                                                    
-                                             MyConfig <-----KConfigDialogManager----> MyConfigWidget *---< myconfigwidget.ui
+                                             MyConfig <-----TDEConfigDialogManager----> MyConfigWidget *---< myconfigwidget.ui
                                                                                                       uic
 
-KConfigBase: defines API for generic config class
+TDEConfigBase: defines API for generic config class
 
-KConfig: functional generic config class that supports merging of cascaded
+TDEConfig: functional generic config class that supports merging of cascaded
          configuration files
 
 KSimpleConfig: functional generic config class without support for cascading
                configuration files.
 
-KConfigBackend: defines API for config backend, t.i. the actual handling
+TDEConfigBackend: defines API for config backend, t.i. the actual handling
                 of the storage method and storage format.
 
-KConfigINIBackend: the standard (and only one so far) class that implements
+TDEConfigINIBackend: the standard (and only one so far) class that implements
                    the config backend using the file-based .INI format
                    for configuration files
 
-KConfigSkeleton: base class for deriving classes that store application
+TDEConfigSkeleton: base class for deriving classes that store application
                  specific options providing type-safety and single-point
                  defaults.
 
@@ -215,9 +215,9 @@ myconfig.kcfg-codegen: Implementation specific code generation instructions
                        just an example name, the application developer
                        choses the actual name.
 
-KConfigDialogManager: Class that links widgets in a dialog up with their
+TDEConfigDialogManager: Class that links widgets in a dialog up with their
                       corresponding confguration options in a configuration
-                      object derived from KConfigSkeleton.
+                      object derived from TDEConfigSkeleton.
 
 MyConfigWidget: Dialog generated from a .ui description file. Widget names
                 in the dialog that start with "kcfg_" refer to configuration