Revert patch pushed in GIT hash 2b84a5e. The patch is good but pushed

prematurely --- needing another patch set not yet pushed to GIT.

1 files changed, 15 insertions, 15 deletions

diff --git a/doc/kdearch/index.docbook b/doc/kdearch/index.docbook
index 3a01f193..8b3a2453 100644
--- a/doc/kdearch/index.docbook
+++ b/doc/kdearch/index.docbook
@@ -1870,8 +1870,8 @@ embedable component that implements the service types
 <literal>KParts/ReadOnlyPart</literal> and <literal>Browser/View</literal>.
 </para></listitem>
 <listitem><para>
-In <application>TDevelop</application> HEAD, most functionality is packaged in
-plugins with the service type <literal>TDevelop/Part</literal>. At startup,
+In <application>KDevelop</application> HEAD, most functionality is packaged in
+plugins with the service type <literal>KDevelop/Part</literal>. At startup,
 all services with this type are loaded, such that you can extend the IDE in a
 very flexible way.
 </para></listitem>
@@ -1890,10 +1890,10 @@ Obviously, a service is not only characterized by the service types it
 implements, but also by some <emphasis>properties</emphasis>. For example, a
 ThumbCreator does not only claim to implement the C++ class with the type
 <classname>ThumbCreator</classname>, it also has a list of MIME types it is
-responsible for. Similarly, TDevelop parts have the programming language they
+responsible for. Similarly, KDevelop parts have the programming language they
 support as a property. When an application requests a service type, it can
 also list constraints on the properties of the service. In the above example,
-when TDevelop loads the plugins for a Java project, it asks only for the
+when KDevelop loads the plugins for a Java project, it asks only for the
 plugins which have Java as the programming language property. For this 
 purpose, KDE contains a full-blown CORBA-like <emphasis>trader</emphasis> with
 a complex query language.
@@ -1919,22 +1919,22 @@ EXTRA_DIST = $(kde_servicetypesdir_DATA)
 
 <para>
 The definition <filename>tdeveloppart.desktop</filename> of a
-<application>TDevelop</application> part looks as follows:
+<application>KDevelop</application> part looks as follows:
 </para>
 
 <programlisting>
 [Desktop Entry]
 Type=ServiceType
-X-KDE-ServiceType=TDevelop/Part
-Name=TDevelop Part
+X-KDE-ServiceType=KDevelop/Part
+Name=KDevelop Part
 
-[PropertyDef::X-TDevelop-Scope]
+[PropertyDef::X-KDevelop-Scope]
 Type=QString
 
-[PropertyDef::X-TDevelop-ProgrammingLanguages]
+[PropertyDef::X-KDevelop-ProgrammingLanguages]
 Type=QStringList
 
-[PropertyDef::X-TDevelop-Args]
+[PropertyDef::X-KDevelop-Args]
 Type=QString
 </programlisting>
 
@@ -1967,7 +1967,7 @@ EXTRA_DIST = $(kde_servicesdir_DATA)
 The content of the following example file
 <filename>kdevdoxygen.desktop</filename> defines the
 <literal>KDevDoxygen</literal> plugin with the service type
-<literal>TDevelop/Part</literal>:
+<literal>KDevelop/Part</literal>:
 </para>
 
 <programlisting>
@@ -1975,10 +1975,10 @@ The content of the following example file
 Type=Service
 Comment=Doxygen
 Name=KDevDoxygen
-ServiceTypes=TDevelop/Part
+ServiceTypes=KDevelop/Part
 X-KDE-Library=libkdevdoxygen
-X-TDevelop-ProgrammingLanguages=C,C++,Java
-X-TDevelop-Scope=Project
+X-KDevelop-ProgrammingLanguages=C,C++,Java
+X-KDevelop-Scope=Project
 </programlisting>
 
 <para>
@@ -2001,7 +2001,7 @@ extern "C" {
 
 <para>
 The type of the factory class <classname>DoxygenFactory</classname> depends on
-the specific service type the service implements. In our example of a TDevelop
+the specific service type the service implements. In our example of a KDevelop
 plugin, the factory must be a <classname>KDevFactory</classname> (which
 inherits <classname>KLibFactory</classname>). More common examples are
 <ulink url="kdeapi:kparts/KParts::Factory">KParts::Factory</ulink>